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[57] 



ABSTRACT 



An Expert System for providing diagnostics to a data 
communications network. Expert information is en- 
tered using a user friendly User Interface which reduces 
need for the participation of a Knowledge Engineer. 
The User Interface including a template for entering a 
plurality of attributes for a hypothesis tree node. 
Among the attributes are an identifier for identifying a 
second node connected to the hypothesis tree node by a 
branch of a hypothesis tree. If the second node has not 
been defined, it is added to and displayed in. a list of 
undefined nodes. Once all attributes for a template are 
completed, an identifier for the hypothesis tree node is 
added to and displayed in a list of defined nodes. 
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very costly to the institution. Similarly, airlines rely 

KNOWLEDGE REPRESENTATION FOR EXPERT upon such systems to track passenger reservations and 
SYSTEM loss of that ability can result in fight delays or cancella- 

tions and loss of customers. 

This application is a division of U.S. Pat No. 3 In a typical network management environment, a 
5,159,685, issued Oct 27, 1992, which is hereby incor- heterogeneous array of switching and transmission 
porated by reference. equipment may produce hundred of alarms each day. 

COPYRIGHT NOTICE Moreover, alarms are sometimes spurious, transient, 

redundant, time correlated, or too numerous to be han- 
A portion of the disclosure of this patent document 10 died at the same time. This makes a network fault diag- 
contains material which is subject to copyright protect nosis task a complex problem where considerable expe- 
tton. The copyright owner has no objection to the fac- rience is required to interpret and isolate network faults, 
simile reproduction of the patent document or the pa- Some experienced (expert) network operators ac- 
ton* disclosure, « it appears in the Patent and Trade- quire or develop strategies and "rules of thumb" in 
mark Office patent file or records, but otherwise re- 15 diagnosing networks. It is desirable to encode such 
serves all copyright rights whatsoever. knowledge into a knowledge base and make the best 

BACKGROUND expert assistant available at all times, and at all loca- 

tions. intimately, the benefits of routine use of such a 
L. Field of the Invention system (called an expert system) include reduced opera- 

This invention relates generally to the field of artific- 20 tional cost less down time, increased network perfor- 
lal intelligence, and more particularly to an expert sys- mance, more effective fault management in the net- 
tem interfaced to, or forming a part of, a data communi- work, and the ability to build and effectively manage 
cations network management system which automates bigger networks. 

network alarm handling and assists the network opera- A major difficulty with typical expert systems is the 
tor in isolating network problems. 25 bottleneck encountered in acquiring knowledge from 

2. Background of the Invention the expert, the job of a knowledge engineer is to act as 

Traditionally, data communications network man- an agent, or go-between to help a domain expert build a 
agement systems have concentrated on providing a set knowledge-based system. This task usually involves 
of fault isolation and test functions that allow an opera- time consuming interviews, lengthy documentation and 
tor to locate, diagnose and isolate network problems. 30 refinement and transformation of the acquired knowl- 

Network problems are often expressed by the target edge into Artificial Intelligence (AI) based languages or 
network devices or objects (e.g. modems, multiplexers, representations. Often, the knowledge engineer and 
etc. in the data communication environment) in the domain expert must work together to debug, extend, 
form of alarms or other error messages. Alarms can and refine the system iteratively. This is usually attribut- 
generally be considered events reported by target net- 35 able to the fact that the knowledge engineer has far less 
work devices when abnormal conditions exist. In some domain knowledge than the expert and the expert has 
networks, alarms are generated autonomously while in far less knowledge about artificial intelligence than the 
others the alarms are actually responses to queries knowledge engineer. Such communication gaps con* 
(polls). Although perhaps the former is more appropri- stantly impede the progress and the process of transfer- 
ately referred to as an alarm, both will be referred to as 40 ring domain expertise into a knowledge-based system, 
alarms for purposes of this document Upon receiving Ultimately, this may lead either to a long development 
the alarms from the network, the network management cycle or a failing system. To further complicate the 
system displays the alarms on the operator's console. matter, providing expert information is a continuing 
One of the network operator's responsibilities is to in- need in data communications networks since the net- 
terpret the alarm and then isolate and resolve the prob- 45 works tend to expand and become larger and more 
lem associated with the alarm in the shortest time span. complex while adding new and different equipment as 
The operator then uses a series of test procedures to time goes on. With this evolution of the network comes 
determine the exact cause of the problem. Once found, an evolution of the products connected to the network 
he may take remedial actions (such as calling for repair (e.g. analog modems to digital devices) and with it a 
or switching in redundant equipment) and then move on 50 change in the knowledge required to diagnose the net- 
to the next alarm. work. 

Sometimes the operator may have difficulty in keep- A second problem with typical expert systems is that 
mg up with the alarms since a single problem may result as the complexity of the application domain increases, 
m many alarms from affected target network devices the classical rule-based system is not adequate. Knowl- 
(network objects). In such cases, often the operator 55 edge management (knowledge acquisition, validation, 
either ignores them, or just waits until a complaint call and maintenance) is also a serious problem when the 
arrives. Furthermore, due to the different levels of net- rule-based system evolves to a certain size. It has been 
work operator' experience in dealing with network claimed (see Buchanan and Short life, 1984, Rule-Based 
faults, the problem could get further complicated be- Expert Systems, Addison-Wesley Publishing Company- 
cause of wrong decisions in attempting to diagnose the 60 or Hayes-Roth Fredrick, 1985, "Rule-Based System"! 
problem and more time than necessary may be taken to Communications of ACM) that the benefit of the rule 
solve the original problem. Such delays can be costly in approach is the ease of modification and extension of 
large networks which are heavily relied upon to quickly the system because rules can be added independently at 
move vast amounts of data in short periods of time to any time. However, more recent articles (see Brug, A. 
carry out the normal course of business. For example, 65 Bachant, J. McDermott, J., FALL 1986, 'The Taming 
large financial institutions rely upon such systems to of RP, IEEE EXPERT; or Jackson, P. 1986, Introduc- 
move large sums of money electronically. Loss of that tion to Expert Systems, International Computer Science 
ability even for a relatively short period of time may be Series; or Rauch-Hindin, W. 1987, Artificial Intelligence 
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in Business, Science, and Industry, Vol 1 & 2, Prentice- 
Hall) have proven in many cases that this is not true for 
medium to large systems such as large data communica- 
tion networks. 

For medium to large diagnostic systems, the rule- 5 
based approach has suffered from at least the following 
problems: 
lack of methodology; 

need for knowledge engineers to transfer knowledge 

into rules; 10 
difficult to control program behavior; 
limited generic processing; 

unanticipated rule interactions during rule updates; 
and 

systems with a large number of rules are difficult to 15 

manage, validate and maintain. 
One alternative to the problems with traditional rule- 
based expert systems is flow-chart-based knowledge 
representation. In the flow-chart knowledge representa- 
tion scheme, the domain knowledge base is simply rep- 
resented as decision trees (or flow-charts), similar to the 
way that many repair manuals are designed. Each deci- 
sion node in the flow-chart is represented by an object- 
schema (data structure plus its associated procedures 
with inheritance). Node objects represent tests, and arcs 
represent the outcomes of tests leading to the next node 
object. A separate Inference Engine is constructed to 
reason through and traverse among flow-chart nodes. 
This flow-chart approach is particularly attractive in its 3Q 
knowledge acquisition capability. The domain expert 
can enter his domain knowledge directly into the sys- 
tem by simply manipulating the flow-chart objects by 
filling in predefined schematic forms. 

The following merits are experienced by using the 35 
flow-chart knowledge representation in capturing the 
domain knowledge: 
domain knowledge is transparent and explicit; knowl- 
edge acquisition is simplified; 
flow-chart browsing can be used to examine the rela- 40 

tions among objects in a more systematic manner; 
flow-chart Inference Engine is completely separated 

from the flow-chart knowledge bases; 
inference processing is quick and effective due to its 
detenninistic nature of the flow-chart representa- 45 
tion; 

facilitates fast incremental knowledge acquisition and 

verification cycle; and 
reduced risk in knowledge maintenance. 
However, with the pure flow-chart-based knowledge 50 
representation scheme, there are still some deficiencies 
that have been realized in the course of capturing do- 
main knowledge, such as; 
lack of formal methodology and knowledge structur- 
ing; 55 
lack of goal (hypothesis) directed reasoning capabil- 
ity; 

lack of top-down problem decomposition methodol- 
ogy; 

state of the world is often not adequately represented; 60 
incomplete and unreliable heuristic knowledge can- 
not be fully captured and expressed; and 
monotonic reasoning is inadequate for large diagnos- 
tics systems. 

The present invention ameliorates these difficulties in 65 
an expert system with advantages such as an enhanced 
User Interface, Inference Engine and knowledge repre- 
sentation as described below. 



4 

SUMMARY OF THE INVENTION 

This invention provides an improved expert system 
with an enhanced ability to interface directly with the 
expert, largely bypassing the need for a knowledge 
engineer and speeding up the knowledge acquisition 
process. It does so by providing a user friendly interac- 
tive interface from which the domain expert can usually 
directly enter the knowledge into the knowledge base. 
Ultimately, the benefits of routine use of embodiments 
of such a system include reduced operational cost, less 
down time, increased network performance, more ef- 
fective fault management in the network, and the ability 
to build and manage bigger networks. In addition, the 
invention provides a mechanism for filtering redundant 
alarms, providing several modes of operation, prioritiz- 
ing goals, suspending or pausing operation as well as 
other features. 

The following objects, features and advantages are 
met by one or more embodiments of the present inven- 
tion. 

It is an object of the present invention to provide a 
knowledge base which the domain expert can quickly 
and easily initialize, debug, display and maintain with 
minima] use of a knowledge engineer. 

It is an advantage of the present invention to provide 
a knowledge based system to assist network operators in 
isolating network faults. 

It is a further advantage of the present invention to be 
capable of preempting the current diagnostic process to 
deal with the more urgent ones, and then continue pro- 
cessing the original diagnosis from where it left off. 

It is another advantage of some embodiments of the 
present invention to employ non-monotonic reasoning. 
Often in network diagnostics, there will only be enough 
information to hypothesize as to the problem. When 
more information becomes available, it is used to refine 
its hypotheses. 

It is a further advantage of the present invention that 
the system is easily modified as expert knowledge and 
the underlying system under diagnostic changes. 

It is a further advantage of the present invention that 
labor intensiveness of knowledge acquisition, documen- 
tation, verification, validation and maintenance is re- 
duced. 

These and other objects, features and advantages of 
the invention will become apparent to those skilled in 
the art upon consideration of the following description 
of the invention. 

In a data communication network according to one 
embodiment of the invention, a method of processing 
alarms from network objects, includes the steps of; 
receiving a first alarm; determining whether or not the 
first alarm is a redundant alarm by comparing the first 
alarm previously received alarms; and placing the first 
alarm in a queue for processing by an inference engine 
if the first alarm is not a redundant alarm. 

In another embodiment of the invention, a method of 
processing events in an expert system, includes the steps 
of; receiving a first event; determining whether or not 
the first event is a redundant event by comparing the 
first event with other events which have been received; 
and placing the first event in a queue for processing by 
an inference engine if the first event is not a redundant 
event. 

A method for prioritizing events for processing by an 
inference engine according to an embodiment of the 
invention, includes the steps of: receiving an event; 



11/14/2003, EAST 



Version: 1.4.1 



5,295,230 

5 6 

translating the event into a goal; classifying the goal as tion to the alarm using the instantiated portion of corre- 

one of a plurality of goal types; assigning a priority spending expert knowledge source, 

number to the goal based upon the importance attrib- A method for entering expert information into an 

uted to the goal type of the goal by a domain expert; expert system residing on a computer, according to an 

tagging the goal with a time associated with occurrence 5 embodiment of the present invention, includes the steps 

of the event; and determining that the goal has a higher of: defining a hypothesis tree node by entering attributes 

prioritization than another goal with the same priority of the hypothesis tree node into the expert system, the 

number based upon the time. attributes including a first identifier for the hypothesis 

An expert network diagnostic system for diagnosing tree node and a second identifier for a node connected 

problems in a communication network in a semi- 10 to the hypothesis tree node by a branch of the hypothe- 

automatic mode according to the present invention, sis tree; adding the first identifier to a list containing 

includes a network manager for performing diagnostic defined nodes; determining whether or not the second 

tests on the network, the diagnostic tests including non- identifier is on the list of defined nodes; determining 

mterruptive tests which do not significantly impact whether or not the second identifier is not a list of unde- 

operation of the network and interruptive tests which 15 fined nodes if the second identifier is not on the list of 

require interfering with function a device in the net- defined nodes; and adding the second identifier to the 

work while the interruptive test is performed. An Ex* list of undefined nodes if the second identifier is not 

pert System determines an appropriate one of the diag- already on the list of undefined nodes, 

nostic tests to be performed to diagnose a problem with In another embodiment of the present invention, an 

the network. It is determined whether the appropriate 20 expert system for use on a computer, includes a mecha- 

test is an interruptive or non-interruptive test and the nism for adding a node for entering expert information 

appropriate test is invoked if the appropriate test is represented by nodes of a knowledge source by enter- 

non-interruptive. Consent of an operator is obtained to ing attributes of the nodes into a template. The knowl- 

perform the appropriate test if the appropriate test is edge source includes at least a hypothesis tree node 

interruptive. 25 terminating in a flow-chart node. The attributes of the 

An expert diagnostic system for providing diagnos- node include a node identifier attribute which gives a 

tics to a diagnostic target in a semi-automatic mode name to a node being added, a node type attribute 

according to an embodiment of the present invention which describes fundamental characteristics of the node 

includes means for performing diagnostic tests. An ap- being added and which distinguishes between hypothe- 

propriate one of the diagnostic tests to perform to diag- 30 sis tree type nodes and flow-chart type nodes, and a 

nose a problem is selected. It is determined if the appro- point-to attribute which gives the name of node branch- 

priate test meets a predetermined criteria. The appropri- ing from the node being added, 

ate test is invoked if the appropriate test meets the crite- In an expert system according to the present inven- 

ria. Consent of an operator is obtained to invoke the tion, a method of applying expert knowledge to a goal, 

appropriate test if the appropriate test does not meet the 35 includes the steps of: posting the goal to a goal queue in 

predetermined criteria. a memory; retrieving a knowledge tree corresponding 

In an expert system according to an embodiment of to the goal; instantiating the knowledge tree; posting 

the present invention, a method of applying expert information from nodes of the knowledge tree to the 

knowledge to a goal, includes the steps of: posting the memory as each node is instantiated so that only infor- 

goal to a display; retrieving a knowledge tree corre- 40 mation from instantiated nodes are posted to the mem- 

sponding to the goal; instantiating the knowledge tree; ory. 

posting information from nodes of . the knowledge tree In the preferred embodiment of the present invention, 
to the display as each node is instantiated so that only an Expert System 10 provides diagnostics to a data 
information from instantiated nodes appear on the dis- communications network 5. Alarms from a Network 
Pky- 45 Manager 24 are received and queued by an Event Man- 
In an expert system for providing diagnostic services ager 117 and then filtered by an Alarm Filter 118 to . 
for a communication network, a method according to remove redundant alarms. Alarms which are ready for 
an embodiment of the present invention for processing processing are then posted to a queue referred to as a 
events reported from the network, includes the steps of: Bulletin Board 120. A Controller 112 determines which 
receiving a current event from the network; comparing 50 one of the posted goals has the highest priority by con- 
the current event with other events previously received sidering a priority number associated with the goal plus 
from the network to determine whether the current a time of arrival of the goal; An Inference Engine 122 
event corresponds to a previously received event in that uses information from an Expert Information Structure 
both the current event and the previously received 111 to solve the highest priority goal by a process called 
event serve to report a common problem in the net- 53 instantiation. The process of solving the goal may be 
work; and discarding the current event if the current interrupted by a pause or suspension in order to perform 
event corresponds to the previously received event tests under the direction of a Network Test Manager 
A method for applying expert knowledge to an alarm 124 or retrieve other information during which time 
ma system to be diagnosed by an expert system residing other goals may be processed. Expert information is 
on a computer in one embodiment of the present inven- 60 entered using a user friendly User Interface 104 which 
tion,. includes in combination the steps of: receiving an reduces need for the participation of a Knowledge En- 
alarm from the system; mapping the alarm to a corre- gineer. Configuration information about the network is 
spending expert knowledge source, the corresponding maintained in a Network Structure Knowledge Base 
expert knowledge source being one of a plurality of 109 by a Network Configuration Module 108. The Ex- 
available expert knowledge sources; retrieving the cor- 65 pert System 10 may operate in any of three modes: 
responding expert knowledge source; instantiating at manual, wherein tests must be approved by or directed 
least a portion of the corresponding expert knowledge by an operator; automatic, where tests are run automati- 
source; and in voicing an inference engine to find a solu- cally without operator intervention; and semiautomatic, 
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where operator approval is required for certain tests FIG. 25, which is broken down in FIGS. 25A and 

such as interruptive test and other tests such as non- 25B due to size, shows a simplified Expert Information 

interruptive tests may proceed without operator inter- Structure for a data communication network diagnostic 

vention. system. 

The features of the invention believed to be novel are 5 FIG. 26 shows a flow-chart of the operation of the 

set forth with particularity in the appended claims. The Controller 112. 

invention itself, however, both as to organization and FIG. 27 shows a flow-chart of the operation of the 
method of operation, together with further objects and Event Manager 117 in retrieving events from the Net- 
advantages thereof, may be best understood by refer- work Manager 24. 

ence to the following description taken in conjunction 1° FIG. 28 shows a portion of the Alarm Queue 114. 

with the accompanying drawing. HO- * 9 shows a portion of the Response Queue 116. 

FIG. 30 shows a portion of the Configuration Queue 

BRIEF DESCRIPTION OF THE DRAWING 113. 

FIG. 1 is a block diagram of a network and network FIG. 31 shows a flowchart of the operation of the 

management system interconnected with the Expert 15 Evcnt Manager 117 in sending events to the Network 

System of the present invention. Manager 24. 

FIG. 2 is a functional block diagram of an embodi- FIG - 32 shows a -portion of the Request Queue 115. 

ment the invention. FIG - 33 shows a flow-chart of the operation of the 

FIG. 3 is a high level flow-chart showing the process- filter 118. 

ing flow for each phase of operation of the Expert Sys- 20 _ f Ia 34 dlustrates the process of instantiation by the 

tern of the present invention. Inference Engine 122. 

FIG. 4 is a goal state transition diagram for the opera- * IG " 35 is brc * cn ^ into fl FIGS k 

tion of the present invention. 35C ™ 6 35 f D ^ du ? '° Sl2e s *! ows of the 

FIG. 5 shows a flow-chart of the operation of the „ °P era f on of the Inference En ^ e 122 of the P resent 

User Interface Module 104. 25 m ^°« . n „ . n . „ ft 

FIG. 6 shows a flow-chart of the operation of proce- Fia # 36 *™ ™ ™™ ew «**WBn* * oard 120 

dure Add Node M constructe d by the Inference Engine using the exam- 

FIG. 7 shows a flow-chart of the operation of proce- * the operation of the 

S»r» o u Attnoutes. 3Q Network Test Manager 124 in queuing requests for 

a ^ £°Z*^ n ™ <h *« of °P eratl0n of P roce * information from the Network Manager 24 

Node Infonnation. fig. 38 shows a flow-chart of the operation of the 

FIG 9 shows a flow-chart of the operation of proce- Network Test Mafl m m retrie ^ g responses 

dU ^^ NOde 7 yP \ ,v • , from the Event Manager 117. 

FIG. 10 shows a flow-chart of the operation of proce- 35 nG 39 shows a flow . chart of ^ operation of the 

dure Delete Node. Network Configuration Module 108. 

FIG. llshowsaflow-chartof the operation of proce- na ^ shows ^ example screen display for ^ 

« 0 ~ , * . Knowledge Acquisition process of the present inven- 

FIG. 12 shows a flow-chart of the operation of proce- t j on 

du i. e ,P i X la ^ Knowledge Source. « FIG. 41 shows an example screen display for the 

FIG. 13 shows a flow-chart of the operation of proce- Systcm Operation process of the present invention, 
dure Show Knowledge Source. 

FIG. 14 shows a flow-chart of the operation of proce- DETAILED DESCRIPTION OF THE 

dure Load Knowledge Source. INVENTION 

FIG. 15 shows a flow-chart of the operation of proce- 45 7^ present invention has broad applications to diag- 

dure Save Knowledge Source. nostic systems in general and may be readily adapted to 

FIG. 16 shows a flow-chart of the operation of proce- a broad varie ty of problems. In particular, the present 

dure Clear Knowledge Source. invention uses a representation of knowledge, referred 

FIG. 17 shows a flow-chart of the operation of proce- t0 nereui M "Expert Information Structure" of "Struc- 

dure Change Test Mode. 50 tared Flow Graph" knowledge which greatly enhances 

FIG. 18 shows a flow-chart of the operation of proce- the extraction of expert knowledge from a domain ex- 

dure Run. pert and facilitates the diagnosis of problems in a data 

FIG. 19 shows a flow-chart of the operation of proce- communication network. The preferred implementation 
dure Run one which runs the ENDS 10 for one goal is a data communication network diagnostic environ- 
only* 55 m ent as will be described below in greater detail. The 

FIG. 20 shows a flow-chart of the operation of proce- invention itself, however, should not be so limited since 

dure Bulletin Board Status which shows the status of it may be broadly applicable to many types of diagnos- 

the Bulletin Board 120. tics systems. 

FIG. 21 shows a flow-chart of the operation of proce- 
dure Resume which resumes operation on a paused 60 Environment of the Preferred Embodiment 
Goal. Turning now to the drawings in which like reference 

FIG. 22 shows a flow-chart of the operation of proce- numerals represent like or similar structures throughout 

dure Exit which exits the ENDS. the various figures, FIG. 1 illustrates an exemplary data 

FIG. 23 shows a functional block diagram of a hypo- communication network 5 interconnected with an Ex- 

thetical automobile diagnostic system used to assist in 65 pert Network Diagnostic System (ENDS) 10 and a 

explaining the present invention. Network Manager 24. The Expert Network Diagnostic 

FIG. 24 shows a simplified Expert Infonnation Struc- System 10 may be synonymously referred to herein as 

ture for an automobile diagnostic system. ENDS, Expert System and the like. The ENDS 10 
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performs diagnostics functions to the diagnostic target In the example network 5, three distinct branches 

network 5 in the preferred embodiment, but the inven- emerge from the FEP 42. A first branch is made up of 

tion itself should not be so limited since other diagnostic a point to point analog connection in which a central 

targets can support a similar Expert System. modem 46 is connected to the FEP 40 to receive and 

The ENDS 10 may be based on an engineering work- 5 send information thereto. The modem 46 is connected 

station 12 such as a Sun/3 TM workstation or other via an analog transmission line 48 to a remote modem 

suitable host on which a multiprocessing operating sys- 50. Remote modem 50 is in rum connected to a terminal 

tern 14 such as the Unix TM operating system and an 52 or other data terminal equipment (DTE) via connec- 

Expert System Programming Environment 16 such as tion 54. 

Carnegie Group's Knowledge Craft TM software has 10 A, second branch of the network starts with central 
been installed. Object-Oriented Programming (OOP) modem 58 which is coupled to the FEP 42. This modem 
languages such as C+ + can also be used to implement 58 feeds a multidrop connection (a connection where 
the present invention. By careful programming, such a morc t** 11 one modem k directly served by the same 
system could be made efficient enough to operate on a transmission line) via a transmission line 60. The first 
personal computer or the like. The Operating System 14 15 on multidrop transmission line 60 feeds a re- 
manages the input and output of data to the ENDS 10 as motc mode™ W which in turn is connected to a terminal 
well as the scheduling of ENDS 10 processes in a w * ^ sccond feeds a remote modem 66 which is 
known manner. The Expert System Programming En- connected to a terminal 68. Similarly, the third drop 
vironment 16 complies, interprets and translates the feeds a remote modem 70 wmch is connected to a termi- 
code of the ENDS 10 processes. To facilitate input, 20 ^J 2 ' *■ » 

output and storage to ENDS 10, a terminal 18 with built , A tn £ d ? f n etwork, starts with a multi- 

in display, printer 20 and disk drive 21 may be attached ? lexcr 74 wlu . ch u ^connected with the FEP 42 via 

to the workstation 12 four conne cUons. The multiplexer 74 has its output 

The ENDS 10 communicates with Network Man- „ ****** * «gh speed modem 78. Modem 78 is coupled 

ager 24 via a connection 22 (for example, an RS 232 * 5 through ^^^point analog transmission one 80 to a 

connection). Network Manager 24 may be similar to T** Modem "it Aen coupled to a multi- 
Network Management systems such as CMS® series 

network management systems commercially Mailable £l!i? nd/or 0thcf ^ tCnnmal "W"** 0>T3> 

SJK^tT T" H w arriS ° n Parkway ' F0rt 30 The Network Manager 24 communicates with the 
I^^aSLS^ ik p T fl V! yS D em ^work objects via, for example, RS232 connections 
Inrl Tl vT? u ^ k 3 V° R ° S " * 98 99 » central cite objects such as multi- 
v £ ishereby mcorporated by reference. p i C xer 74 and modems 46, 58 and 78 respectively. These 
Tht Network Manager 24 ^ preferably based upon a objects communicate ^ & c rC maiiu*n7 network ob- 
mmicomputer26, suchasaDECMicrovax IlTM mini- 35 jccts ^ , multiplexc d secondary diagnostics channel 
computer, or engineering workstation on which a multi- (frequcncy division multiplexed in the preferred em- 
processing operating system 28 such as Unix TM operat- Modems capable of doing so are commer- 
T W Cm w a database J na Hf 3( L such ™ cially available as the Racal-Milgo Omnimode ® series 
le® database manager by Oracle Corporation have modems. Multiplexers with such capabilities are com- 
been installed. Via connection 22, ahjrms are passed 40 mC rcially available as the Racal-Milgo Onmimux® 
from the Network Manager 24 to ENDS 10. Similarly ^vies multiplexers. These connections enable the Net- 
commands, much like those an expert operator would work managcr 24 to communicate with the entire net- 
enter from the Network Manager 24's terminal 33 are work 5 through these central site objects. Those skilled 
sent via connection 22 from the ENDS 10 to the Net- m the art will appreciate that the network shown in 
work Manager 24 In other embodiments, the Network 45 FIG. 1 is somewhat simplified compared to real world 
Manager 24 and ENDS 10 may be installed on a Mi- networks and is presented only as a mechanism for 
crocomputer and other environments may occur to understanding the general environment of the inven- 
those skilled in the art. The operating system manages tion. 

the input and output of data to the Network Manager as Messages passed between the Network Manager 24 
well as the scheduling of Network Management pro- 50 and the network objects include alarms, informational 
cesses, The database manager 30 manages data describ- messages and instructions. Network objects can signify 
ing the network configuration in a conventional man- malfunctions by sending alarms to the Network Man- 
ner. To facilitate input to and output from the Network ager 24. Network objects can send informational mes- 
Manager 24, a disk drive 32 terminal 33 and printer 34 sages in response to requests from the Network Man- 
are attached to the minicomputer. 55 ag er 24. The Network Manager 24 can send instructions 
In the present example the diagnostic target, a data to network objects to perform diagnostic tests or other 
communication network 5, includes a host computer functions such as loop back tests or switching functions. 
(Host) 40 coupled to a Front End Processor (FEP) 42 The Network Manager 24 and the central network 
via connection 44 which is further coupled to a network objects 46, 58, 74 and 78 can exchange alarms, informa- 
of objects in this example including data modems and 60 tional messages and instructions directly or through a 
multiplexers. In general, the network may also include dedicated network such as a dial-up network or an X.25 
other objects such as Digital Service Units (DSU's), network. Remote objects, i.e. network objects located 
encryption devices, restoral devices, switches, terminal at remote sites, communicate with the Network Man- 
adapters, Packet Assemblers and Disassemblers ager 24 through the central objects via a multiplexed 
(PAD's) as well as other such devices. In general, the 65 in-band or out-of-band secondary diagnostic channel in 
network 5 shown in FIG. 1 is very simple compared to a known manner. 

real life data networks and is intended only for illustra- As previously mentioned, some network manage- 

tive purposes- ment system's diagnostics are not autonomous alarm 
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based. However, equivalent information is generally 
available at the Network Manager 24 for use by the 
expert system 10. For purposes of this discussion, all 
will be referred to as alarms. 

When the Network Manager 24 receives an alarm, it 
informs the operator via the terminal 33 and/or printer 
34. The operator can then use the terminal 33 to send an 
instruction to the object which sent the alarm. For 
example, he can instruct the sending object to perform 
diagnostic tests and send back the results. Upon deter- 
mining the nature of the malfunction, the operator can 
send remedial instructions to the object such as lower- 
ing transmission speed or switching in a redundant ob- 
ject or he can take other corrective actions such as 
contacting the telephone company for repairs. 

Through the connection 22, the ENDS 10 can com- 
municate with the network 5 as if it were the operator 
of the Network Manager 24. The Network Manager 24 
forwards alarms to ENDS 10. ENDS 10 can then send 
instructions to network objects requesting more infor- 
mation or initiating various diagnostic tests. Upon de- 
termining the nature of the malfunction, the ENDS 10, 
in conjunction with the Network Manager 24 can send 
remedial instructions in some cases such as switching in 
redundant equipment or rerouting traffic. 

Those skilled in the art will appreciate that the system 
and network shown in FIG. 1 is intended to be illustra- 
tive and that many variations are possible. For example, 
the Network Manager 24 and the ENDS 10 could possi- 
bly coexist on the same computer system in an alterna- 
tive embodiment so that duplicate operating systems, 
disk drives, printers and terminals may not necessarily 
be required. Of course, such a system might require a 
more powerful multitasking computer system than 
those individually required by the Network Manager 24 35 
and the ENDS 10 in the illustrative embodiment in 
order to achieve similar performance speed. Similarly, 
great variety can exist in the actual communications 
network. It should also be recalled that the Expert Sys- 
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EVENT MANAGER 117— Receives "events" from 
the Network Manager 24 and determines what kind of 
event it is (alarm, response, or configuration), con- 
structs a "record" using the information about the event 
and places the record in the appropriate queue. (Alarm 
Queue 114, Response Queue 116, or Configuration 
Queue 113). The Event Manager also receives request 
from the Network Test Manager 124 and places them in 
Request Queue 115 for forwarding to the Network 
Manager 24. Responses in the Response Queue 116 are 
answers to requests and are forwarded to the Network 
Test Manager 124. Alarms are sent to the Alarm Filter 
118. Configuration information is sent to the Network 
Configuration Module 108. The Event Manager 117 
also prioritizes the events where required. 

ALARM FILTER 118— Posts alarms in the form of 
goals to the Bulletin Board 120 after removing redun- 
dant alarms through a filtering process. 

NETWORK CONFIGURATION MODULE 
108 — Manages the Network Structure Knowledge Base 
110 by interpreting information in the Configuration 
Queue 113 and updating the Network Structure Knowl- 
edge Base 110 accordingly so that the Expert Network 
Diagnostic System (ENDS) 10 always has a current 
picture of what the network 5 looks like. 

NETWORK TEST MANAGER 124-Sends in- 
structions to the Network Manager 24 requesting tests 
and further information needed to perform diagnostic 
functions. 

BULLETIN BOARD 120— A global data structure, 
which could also be thought of or referred to as the 
Goal Queue, which holds goals to be processed by the 
Inference Engine 122. The Bulletin Board 120 also dy- 
namically posts goals, tests etc. as processed by the 
Inference Engine 122 in a process referred to herein as 
'instantiation*. 

STATIC KNOWLEDGE BASE 109— Stores the 
Expert Information Structure 111 which holds the 
knowledge of the Domain Expert 101 in a form usable 



tern of the present invention can be used for purposes 40 by the Inference Engine 122. Also stores the Network 

Structure Knowledge Base 110 which contains informa- 
tion about the makeup and structure of the Network 5 



other than network diagnostics. 

Overview of the Invention 

The architecture of the ENDS 10 is illustrated in 
some detail by the functional block diagram of FIG. 2 
while the overall operational flow is described in con- 
junction with FIG. 3 and the defined states of goals are 
covered in FIG. 4. In order to understand the invention, 
its overall structure is first briefly presented in conjunc- 
tion with FIG. 2. The overall flow of operation will 
then be discussed in conjunction with FIG. 3, followed 
by a discussion of the state diagram of FIG. 4. At this 
point a more detailed discussion of the interaction and 
operation of each of the individual components of FIG. 
2 will proceed. 

ENDS 10, in its preferred form, comprises several 
parts: a User Interface Module 104, a Network Configu- 
ration Module 108, a Static Knowledge Base 109 com- 
prising a network structure knowledge base 110 and an 



and is maintained by the Network Configuration Mod- 
ule 108. 

45 INFERENCE ENGINE 122— Determines which 
rules in the Expert Information Structure 111 to apply 
and applies rules stored in the Expert Information 
Structure 111 to goals on the Bulletin Board 120 to 
determine cause of Alarms. It does so by instantiating a 
50 goal tree for each goal in accordance with the Expert 
Information Structure 111. If further information is 
needed, it queries the user or the Network Test Man- 
ager 124 to obtain the information. Processing of a goal 
may be paused or suspended to allow processing other 
55 goals while tests are being performed. 

USER INTERFACE 104— Provides Operator 128 
or Domain Expert 101 with prompts, templates, menus, 
etc. to allow for easy entry of information or queries. 
The User Interface 104 operates in two modes. Expert 



expert information structure 111, a Controller 112, an 60 Knowledge Acquisition and System Operation, to pro- 



Event Manager 117, an Alarm Filter 118, a Bulletin 
Board 120, an Inference Engine 122, and Network Test 
Manager 124, as seen in FIG. 2. 

The basic function of each of these components is 
described below. Although some of the terminology 65 
used in these brief descriptions has not yet been intro- 
duced, this summary will be useful as a glossary for the 
reader's later reference. 



vide a user friendly environment in which the Domain 
Expert 101 or Operator 128 may interact with the Ex- 
pert System 10. 

CONTROLLER 112— Schedules and invokes the 
above modules in appropriate sequence and oversees 
operation of the Expert Network Diagnostic System 
(ENDS) 10 generally. Selects one of posted goals on 
Bulletin Board 120 for active status so that is can be 
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processed by the Inference Engine 122 by examining The "data" referred to above takes several forms. In 
the goal's priority number as well as its arrival time. general, the data start out as an "event", which as used 

FIG. 3 depicts the overall flow of the operation of the in this example communications network diagnostic 
invention. Recall that the invention operates in one of system, is a message either from the Network Manager 
two basic modes: Expert Knowledge Acquisition, and 5 24 to the ENDS 10 or from ENDS 10 to the Network 
System Operation. The Expert Knowledge Acquisition Manager 24. Three types of events are sent from the 
mode is used to allow the Domain Expert 101 (or the Network Manager 24 to the ENDS 10 via communica- 
Operator 128) to enter domain expert knowledge into tipn line 22. First, a configuration event contains infor- 
the system. The System Operation mode is used during mation about the. configuration of the network 5. Sec- 
actual operation of the system for performing diagnos- 1° ond » alarm is a report of a network malfunction, 
tics functions. For now, let us assume that the know)- Third, a result event contains the results of a test or 
edge from the Domain Expert 101 has already been <l uer y such a network component test or a query of a 
entered into the system and that the system is in the database for information. A fourth type of event, a 
System Operation mode. Later, the Knowledge Acqui- request event, is sent from the ENDS 10 to the Network 
sition process will be treated in detail. 15 Manager 24 via communication line 22. It contains a 

Referring to FIG. 3, when the system is started, it re< i ucst for a network device to perform a diagnostic 
enters a data acquisition phase 130 in which data (in the test or a request to retrieve information describing a 
form of "events" from the Network Manager 24) relat- network object's configuration from the data base man- 

ing to the performance of the network are reported to a ^,^°* , 

the Event Manager 117. In general, these data may 20 <X&<*«*t interest at this point is the "alarm" event 
represent network malfunctions, as will become clear w!uch tho ?8* T of ™ply report issued from 
later. These data are then passed to the Alarm Filter 118 8 network object (or Network Manager) indicating that 
which operates in conjunction with the Network Struc- lt has detected a possible malfunction or other error 
ture Knowledge Base 110 to perform analysis and filter- „ c ? n * !t ™ ? hl 5 h n ? ds ^T?ti ****** 
ing function; to take placeafa data filter and analysis 25 phaS * ?*L dc ^ s with receipt °/ ^^ md 
phase 131. In this phase, the data are filtered by remov- "T^* T Ma ? ge l" 7 ^ ata ™ 
ing redundant dala and placed in a form suhable for S5S ^tll ^ 

posting on the Bulletin Board 120, J"* 9X1 "T^^St given by the Event Manager 117. 

rZ t i a 1 !v £ u*- r> , , w ^ , During the data filter and analysis phase 131, these 

Once placed on the Bulletin Board ^120, the system „ rccor * frf ^ rcdundant( [ wo network objects 
moves into a diagnostic : phase 132 w,th respect to the rcport detectin the ^ ^4 ction) m postedtothe 
data posted on the Bulletin Board 120. In this stage, data B ^ Board 6 no * which ^ mt ^ m Verted to 
having highest priority of all data posted on the Bulletin « ^ ^ ^ ft bmes ? ^ of ^ m to fmd 
Board 120 are placed in an active state. A knowledge thc t0 ^ roblem wnich resulted m ^ ^ 

source associated with the particular type of data is 33 corresponding to these goals. Hereafter, the terms 
retrieved and operated upon by the Inference Engine "event", "goal", "alarm" and "record" may be used 
122 in conjunction with the Expert Information Struc- somewhat interchangeably to represent data structures 
ture 111 (i.e. the knowledge of the Domain Expert 101) corresponding to the same "event". The term "node" is 
and if funher information is required to diagnose the ^ hcrcin to dcscribe flowK:hart Uocfc ^ bypothe- 
problem the Network Test Manager 124 may be in- ^ sis Uee node s, but those skilled in the art will appreciate 
yoked to perform specific tests on, or retrieve further that ^ tcrm » node » is sometimes used in the literature 
information about, the network via thc Network Man- t0 describe that which is referred to as a "record" 
ager 24. herein. Use of the term "record" is intended to minimize 

When such further tests are required, often the pro- confusion and not as a technical limitation for the par- 
cess of performing the tests may take a long time or 43 ticular type of data structure used in implementation, 
require undesirable interruption of normal network As shown in FIG. 4, goals may be considered to have 
operation. In such cases, the Operator 128 may wish to U y 0 f f 1V e states in the preferred embodiment of the 
pause operation on that data until a later time if a man- present invention: posted, active, suspended, paused or 
ual mode of operation is in use. In an automatic mode of dormant. The two remaining states, start and finished 
operation, the system may automatically suspend opera* 50 are shown for clarity of explanation. The transition 
tion on that data untfl the requested further information from one state to the next is shown in the state flow 
or test result is received. While waiting for the test diagram of FIG. 4. A start state 134 is defined as a 
result or further information to be received, the data condition where thc system is awaiting receipt of an 
being processed reenter the data acquisition phase 130. alarm event. When an event is received, it is held in 
This allows the system to process other date ("events") 55 queue at the dormant state 135 until the system can post 
in the meantime. Resumption of processing of the data the event. State 136 (posted) represents goals which are 
takes place at the point where processing was paused or posted on the Bulletin Board 120, after filtering by the 
suspended. When the diagnostic phase is completed, the Alarm Filter, either as a result of an alarm event, a test 
system enters the interpretation phase 133. In this phase, result event or resumption of a user paused event. In 
the results of the diagnostics are logged to a printer, a 60 this state, when the goal has the highest priority of all 
disk file and/or the screen for use by the operator who goals on the Bulletin Board 120, it is selected for further 
may be required to take various corrective actions such processing. Once the posted goal has been selected for 
as ordering repairs or replacement of defective compo- processing by the Inference Engine 122, the state 
nents, contacting the telephone company, etc. changes to active state 137. In the event of suspension of 

Each phase of the above process is controlled, in- 65 processing by the test manager 124 (eg. to perform a 
voked and scheduled by the Controller 112. The Con- lengthy diagnostic test), the state changes to suspended 
troller 112 may be thought of as a supervisor of the state 139 until receipt of a test result event once again 
operation of the system. results in change to the posted state 136. 
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While in active state 137, the goal may be paused disruptive to business* by the Expert Network Diagnos- 
under certain circumstances by the Operator 101 plac- tic System (ENDS) 10 of the present invention. In the 
ing the goal in paused state 140 until resumed by the manual mode, all tests or actions are individually under 
user at which point the goal is returned to the posted the control of the operator at all times so that all tests 
state 140. (It may be desirable to pause the goal rather 5 must be ordered by the Operator 128 before they can be 
than begin a lengthy interruptive test which would performed. In the automatic mode, all tests are automat- 
disrupt communications,) In active state 137, when ically performed by the Expert System 10 (ENDS) 
diagnostics is completed, the goal moves into a finished regardless of whether or not the test will result in an 
state 144 with respect to the goal of interest The fin- interruption. In the above environment, the automatic 
tshed state 144 of FIG. 4 corresponds roughly to the 10 mo de might be invoked during evenings and/or week- 
interpretation phase 133 of FIG. 4. The diagnostic ends when user data traffic is low or nonexistent The 
phase 132 of FIG. 3 corresponds to the active, posted, tests can then be logged by the system for examination 
suspended and paused states of FIG 4. The dormant by fa Operator 128 during working hours. In this man- 
and posted states 135 nd 136 of FIG. 4 correspond ner , problems such as the above can be detected and 
roughly to the data acquisition phase 130 and the data 15 corrective action taken at times when business will be 
filter and analysis phase 131 of FIG. 3. nummally disrupted. The third mode, Setm-Automatic, 

The system may be implemented or operated (for may generally be defined as anything in between. In the 

example by selection from a menu) w any of three referred embodiment, the Semi-Automatic mode is 

modes durmg Sys em Operation according to the pre- des igne4 so that non-mterruptive tests are automatically 

ferred^ embodiment The modes are Automatic, Manual 20 pe rfonned whilc mt erruptive tests require consent or 

and Serm-Automatic. To understand the rational for b the Q \^ j ^ £uon the Oper- 

these modes, let us digress briefly to a discussion of the , , . 7 «"* umu*™, " 1C 

a*** ™nr*»L'*~>+i™ fL ' ator 128 can make a judgment as to whether or not the 

data communication environment . . _ . J ° . - 

In the data communication and network management fZ^lL^rfTT 9 *Z? °1 

environment it must be remembered that it is often the 25 {tm ? e rf ^ * y work ^d etc.). to warrant 

case that many alarm are of negligible importance due a d T IS ? K P / f °S dU ^T "J"*, -r 

to transient phenomenon. FurtL* it should be noted t of semi-automatic mode, if the 

that often alarms are produced due to degradation of teSt * mte ™P" ve . tn ' ™» be presented with a 

communication, as for example in the case of marginal ««f on H or ^tructioE ito perform a particular testmthe 

transmission line which in affected by changes in 30 ^^StSSl^^^ 

weather which make it impossible to transmit at the Spcf it t- 

highest data rates over such lines. In this example, a 19.2 *7lV~f~ . . . 

Kbps modem might be forced to reduce its data rate to At this, the Operator 128 can either pause the process 

16.8 Kbps in order to cope with the poor transmission rf no [ " Wropnate time to perform the te* or 

line without introducing transmissioVerrors. Such a 35 Perform the test and enter the answer in the blank. If the 

rate change is normally prompted by an increased error °P erator 128 P auses ?* tes }> 06X1 la ? r retum to enter 

rate or rc-transmission rate at the higher data rate and ^answer and continue the diagnostic : process, 

often causes an alarm to be sent to the Network Man- To relate the various modes to FIG. 4, the suspended 

ager 24. In order to diagnose this problem, it might be state 18 ««™dl?y J? Network Test Manager 124 in the 

necessary to perform interruptive tests, i.e. tests which 40 mode The Paused state is entered by the 

interrupt communication such as loop-back tests. Operator 101 in the manual mode. A hybrid of these is 

Consider the case of a financial institution operating used m the Semi-Automatic mode depending upon 

during normal business hours. If the above modem is whether or not the test is interruptive. 

serving all of the tellers in the financial institution, the Referring back to FIG. 2, a more detailed description 

lowering of the data rate to 16.8 Kbps may go unno- 45 of ^ e interaction of the various functional blocks fol- 

ticed, depending upon the work load at the time. Worst lows: 

case, such a data rate change will slow down response Expert information is entered into ENDS 10 by a 

time of the tellers 1 terminals to some degree. If an inter- Domain Expert 101 (someone with extensive experi- 

rapti've diagnostic test is run, the modem must be taken cnce fa diagnosing problems with this network) in gen- 

completely out of service for a period of time varying 50 cra *- Because of the structure of the expert information 

from several minutes to much longer in order to diag- ^ d °y present invention, the services of a knowl- 

nose the problem. If this were done, the tellers would be engineer are typically not needed or are minimal, 

completely unable to process transactions and customer The Domain Expert 101 uses the terminal 18 to enter 

lines would back up until service was restored. the rules and procedures (expert knowledge) he has 

Obviously, in the above scenario poor weather is 55 found effective in diagnosing the network 5. The User 

slowing down communication, but little can be done Interface 104 facilitates this data entry by providing an 

about it without disrupting service. Since the disruption interactive user-friendly interface as will be described in 

of service for diagnostics would be more damaging to morc detail under the heading "User Interface". As the 

the day to day transaction of business than simply living User Interface Module 104 receives the data, it stores it 

with the decreased data throughput for a while, it is 60 in a data structure called the Expert Information Struc- 

desirable not to implement interruptive diagnostic tests ture 111. 

at this time. It is, however possible that there are non- Network structural information is entered into 

interruptive tests which might pinpoint the problem to ENDS 10 by the Network Configuration Module 108. 

a transmission line which needs service. Such tests The Network Configuration Module 108 uses the Event 

might be readily run without disrupting business and 65 Manager 117 (described below) to get configuration 

might lead to correction of the problem. information from the Data Base Manager 30 within the 

By allowing the three separate modes of operation, Network Manager 24. The Network Configuration 

such situations can be dealt with, in a manner least Module 108 stores a subset of the information in the 
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Network Manager's Data Base Manager. 30 in a data from modem 58 should be given a higher priority num- 
structure called the Network Structural Knowledge ber, in general, than a similar alarm from modem 61 
Base 110. Since the Network Manager 24 can be called since a failure at modem 58 would disrupt communica- 
upon to retrieve more detailed information if required, tions to three terminals whereas a failure at modem 61 
the Network Structure Knowledge Base 110 can be less 5 would be more likely to only affect terminal €4. Of 
detailed than the Network Manager's Data Base Man- course, critical paths of communications, as in military 
ager 30. In alternate embodiments, it may be eliminated environments, can be assigned higher priority than less 
altogether in favor of the Network Manager's Data critical communications links. Those skilled in the art 
Base Manager 30 (e.g. in a hybrid network manager- will appreciate that numerous criteria can be used to 
/Expert System Knbodunent). The Network Configu- 10 establishes priority numbers including the experience of 
ration Module 108 also uses the Data Base Manager 30 the Domain Expert 101, business considerations, secu- 
of Network Manager 24 to update tht > Network Struc- rity considerations or system policies, 
toe Knowledge Base 110 while the ENDS 10 is per- Sarins may be best han- 

for^gdiagnosncfuncbons. „• dlrf as most recent havmg higher priority while other 

. the Network Structure Knowledge Base 110 15 ^ ^ * ^ handle? as least recent having 

can use the User m her riori Fof , m ^ ^ m * 
Interface 104 to instruct ENDS 10 to perform network rate ma *y ^ due to t ^Jbafi pheno^,,,, ^ d older 

Network Manager 24 and ENDS 10. All commuiuca- . , . . . mA ~. j e u j • • 

tion between the ENDS 10 and the Network 5 are ^SStii TJ!^i^^^SS^ " 
handled as events preferably left up to the Domain Expert 101. 

Upon receiving one of the first three types of events ^15^2?^ ^ 1^2? 

described above (configuration, alarm oHesult) the 25 * pr 5*f S * ta ? ed m ** Bu ? Ctm *°5 d ^ 
Event Manager 117 decodes the event to determine the ™ c *T ™ ^Jf?.*' ***** v g 

type of event and attributes such as the sending object, ^rx^uon from the associated Alarm Record, the 
identification number and time received by the Net- ^nnrtm Structure 111 and the Network 

work Manager 24. The Event Manager 117 places these Knowledge Base 110 to determine the mal- 

attributesin data structures called records as previously 30 6111011011 whlch the ^arm associated with the 

described. Next, the Event Manager adds records with * oal , to rcmed y **« malfunction. If the Inference 
network configuration information to a Configuration Engine 122 determines that it needs more information to 
Queue 113 associated with Event Manager 117. Re- Process the goal, it requests it through the Network 
cords with alarm information are added to an Alarm Test Mana ger 124 described below. 
Queue 114 associated with Event Manager 117. Re- 35 The Inference Engine 122 uses the information in the 
cords with test result information are added to a Re- aknn record ^ Network Structural Knowledge 
sponse Queue 116 associated with Event Manager 117. Base 110 t0 determine which Expert Knowledge 

Upon receiving a request for a diagnostic test from Source applies to the alarm. This may be done using a 
the Network Manager 24, the Event Manager 117 en- look-up table maintained in the ENDS 10. As the Infer- 
codes the test request into a request event understand- 40 cncc Engine 122 applies the Expert Knowledge Source, 
able by the Network Manager 24 and sends the event 11 constructs a tree below the goal node on the Bulletin 
via communication line 22 to the Network Manager 24. Board to keep track of what it has done so fair in a 

The Controller 112 invokes the Alarm Filter 118. The process which will be referred to as "instantiation" and 
Alarm Filter 118 takes alarm records from the Alarm described later in more detail under the heading "Infer- 
Queue 114 and determines whether or not the alarms 45 cncc Engine**. In so doing, if it determines that it needs 
are redundant. If so, the Alarm Filter 118 deletes the morc information to complete the reasoning, it can 
redundant alarms. The Alarm Filter adds records cone- suspend the reasoning and later resume where it left off. 
sponding to non-redundant alarms to a global data If it determines that some action should be taken either 
structure called the Bulletin Board 120. to determine or remedy the problem, it sends a request 

The Controller 112 then selects the next goal on the 50 for information to the Network test Manager 124. The 
Bulletin Board 120 to be processed. Controller 112 Inference Engine 122 relinquishes control upon deter* 
makes this determination based on three factors: status mining that it needs more information to diagnose or 
(whether the goal is ready to be processed), priority remedy the problem, or upon exhausting the expert 
number and the amount of time since the alarm was knowledge that apply to the alarm, 
received by the ENDS 10. 55 The Network Test Manager 124 is called from the 

the Domain Expert 101 may determine whether the Inference Engine 122 with a request for information, 
time factor should operate such that the more recently The invention takes different action depending upon 
received goals take priority or whether the least re- whether it is operating in manual, semi-automatic or 
cently received goals take priority. The priority number automatic modes. If the invention is operating in a man- 
is assigned by the Domain Expert 101 according to his 60 ual mode, the Network Test Module prints a query to 
experience. For example, a lost power alarm from a the terminal 18 and returns the user's 128's response. If 
central multiplexer such as 74 would likely have a the invention is in an automatic mode, the module sends 
higher priority than a high error rate alarm from a point the request to the Event Manager 117, which in turn 
to point connection modem such as 50. Similarly, prior- sends the request to the Network Manager 24. The 
ity numbers can relate to the physical location of the 65 Network Manager 24 then obtains the result and for* 
device. In general, devices located closer to the central wards the result to the Response Queue 116 where it 
site are often more likely to be of higher importance can be retrieved by the Event Manager. In the semi- 
than at remote sites. In FIG. 1, for example, an alarm auto mode the choice of which of the above actions to 
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take depends upon the nature of the test required as 101 to remove a Knowledge Source from working 
described previously in the preferred embodiment. memory. 

Finally, the Controller 112 invokes the Network CHANGE TEST MODE 175: Used by the System 
Configuration Module 108 to update the Network Operator 128 in the System Operation process to select 
Structural Knowledge Base 110 if it has been changed 5 automatic, semi-automatic or manual operation of the 
since the last time this module ran, as explained above. Expert System 10. 

RUN ONE 177: Used by the System Operator 128 in 
User Interface the System Operation process to invoke the Expert 

1. High Level Menu and Overview System 10 for a single goal only. 

Turning now to FIG. 5, a flowchart illustrates the *\ * UN ™-"" sd by Systm Op^r ^ in the 
high-level I operation of the User Interface Module 104. ^ tem °P erat,on P rocess 10 mvoke E W ert System 
As discussed previously, the module has two distinct " . __ M Bri . Dri , fi , ... . . 

purposes: Expert Knowledge Acquisition and System * BULLETIN BOARD STATUS 182: Used by the 
Option. FIGS. « through 16 show the operation of l5 'tL&rfltSSffi 
the Expert Knowledge Acquisition functions. FIGS. 17 ™ e °" BttUetm *"* 

through 22showthe oration of the System ^ration EVENT/ALARM STATUS 183: Used by the Sys- 
funcnons. The bottom blocks 156 through 186 of FIG. Operator 128 « the System Operation process to 

5 should be conadered procedure labels which are car- ^ £ e ^ of ^ ^ ^ ^ £ BuUetin 
ned over to FIGS. 6-22 In operation, the procedures 20 Board & to a 8creen ^ Similar m operation t0 
are shown as menu selections which may be selected by bulletin BOARD STATUS 182 except that differ- 
using a pointing device such as a mouse. OAer methods M is di , # m a 

of human interface may also be used including direct fbaaon not discusse d m dete a. 
entry of commands correspondmg to the various proce- resume 184: Used by ^ System Operator 128 in 
dures. as will be appreciated by those skilled in the art 25 ^ ^ ^ eration t0 processing a 

Each of the menu selections (procedures) are discussed naused coal 

bri ?^v?^ following. EXIT 186: Used by the System Operator 128 in the 

ADD NOTE 156: Used in the Knowledge Acquisi- s tem Operation process or the Domain Expert 101 in 
tion process by the Domain Expert 101 to add a knowl- ^ knowledge Acquisition process to exit the Expert 
edge node to the Expert Information Structure 111, JU System operation 

MODIFY NODE INFORMATION 158: Used in ^ D £ main Expert 101 uses the knowledge acquisi- 
the Knowledge Acquisition process by the Domain tion functions t0 cntcr , modify disp i ay information 
Expert 101 to change the information in an already in tne Bxp9n Informa tion Structure 111. The Expert 

w^S^^^^I',^ „ , ^ , 35 Information Structure 111 is explained in detail below, 

MODIFY NODE TYPE 160: Used in the Knowl- 35 but essentially it comprises a number of Expert Knowl- 
edge Acquisition process by the Domain Expert 101 to edge SourceS( one ^sockx** with each possible type of 
ch *?Jf the knowledge node type. alarm and tracked in a table. Each knowledge source in 

DELETE NODE 162: Used in the Knowledge Ac- tlirn in C i ud es a number of data structures called 
quisition process by the Domain Expert 101 to remove ^ "knowledge nodes" or "nodes". Each type of knowl- 
an already established knowledge node. node nas a set Q f attributes associated with it to 

COPY NODE 164: Used in the Knowledge Acquisi- storc characteristics of the node knowledge such as its 
tion process by the Domain Expert 101 to produce a name , its type, and the nodes to which it points. The 
new knowledge node which is a copy of an existing Domain Expert 101 defines a knowledge node by as- 
knowledge node in order to simplify adding similar 4$ signing values to its attributes, 
knowledge nodes to the Expert Information Structure The program flow for User Interface Module 104 
111 . begins at start block 150. Block 152 determines which 

DISPLAY KNOWLEDGE SOURCE 166: Used in function the Domain Expert 101 wants to invoke by 
the Knowledge Acquisition process by the Domain reading selections made by the Domain Expert 101 
Expert 101 to produce a graphic display of a currently J0 selected from a menu, preferably using a pointing de- 
existing (or currently being built) Knowledge Source. vice. Block 154 corresponds to a "case" command and 

SHOW KNOWLEDGE SOURCE 168: Used in the selects the next block based on the selection of the Do- 
Knowledge Acquisition process by the Domain Expert main Expert 101: Add Node 156, Modify Node Infor- 
101 to produce a text display of a currently existing (or mat i 0 n 158, Modify Node Type 160, Delete Node 156, 
currently being built) Knowledge Source. 55 Copy Node 164, Display Knowledge Source 166 t Show 

LOAD KNOWLEDGE SOURCE 170: Used in the Knowledge Source 168, Load Knowledge Source 170, 
Knowledge Acquisition process by the Domain Expert Save Knowledge Source 172, Clear Knowledge Source 
101 to retrieve a saved Knowledge Source from disk 174, Change Test Mode 175, Run One 177, Run 178, 
storage and load it into working memory. Bulletin Board Status 182, Resume 184, Exit 186, event- 

UPDATE ALARM MAP: Used by the Domain 60 /alarm status 183, and update Alarm Map 17L Based on 
Expert 101 in the Knowledge Acquisition process to the Domain Expert's selection, program control flows 
update a map (table stored in 109) relating alarms to to one of the procedures described by the flow-charts of 
knowledge sources. FIGS. 6 through 22. 

SAVE KNOWLEDGE SOURCE 172: Used in the 
Knowledge Acquisition process by the Domain Expert 65 1 "P** Knowledge Acquisition 

101 to save a Knowledge Source to a disk file. The process of acquiring the Expert Knowledge is 

CLEAR KNOWLEDGE SOURCE 174: Used in the described in detail in conjunction with the flow-charts 
Knowledge Acquisition process by the Domain Expert of FIGS. 6-16. 
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The flow-chart in FIG. 6 illustrates User Interface 
104 operation after selection of the Add Node proce- 
dure 156. Block 190 gets the name of the knowledge 
node that the Domain Expert 101 wants to add. It does 
so by, for example, allowing the user to type a name or 
to select one of the nodes on the list of nodes which are 
referred to by other nodes but not yet defined (the list of 
undefined nodes) using the terminal's cursor or a point- 
ing device such as a mouse. Block 190 would preferably 
only accept typed names if there were no existing de- 
fined; nodes by that name using conventional error trap- 
ping techniques* Next, 192 gets the type of node the 
Domain Expert 101 wants to add. One way it could do 
so is by displaying a list of the node types and allowing 
him to select one. Other techniques will occur to those 
skilled in the art. Block 194 calls a function to get the 
remaining attributes (those other than name and type) of 
the node being added. The function prompts the user 
for the remaining attributes of a node of the selected 
type which the user enters by conventional means. 

In the preferred embodiment, this is done by present- 
ing the Domain Expert 101 with a template of node 
attributes to be filled in. Since different node types re- 
quire different sets of attributes, different templates may 
be presented for different node types. Using Object-Ori- 
ented Programming, such individual templates may 
inherit appropriate attributes from a generic template. 

To help ensure the integrity of the knowledge source, 
two stacks are maintained which may be displayed to 



22 



10 



IS 



20 



25 



to hypothesis tree nodes leading to flow-chart nodes in 
the present invention, flow-chart nodes may also lead to 
hypothesis tree nodes. 

CONFIRM nodes are nodes which return conclusion 
values to the lowest level hypothesis node which leads 
to the flow-chart, that is, they provide the solution to 
the hypothesis. 

FACT nodes are nodes which simply print or display 
a fact when instantiated. 

COUNT nodes are nodes which increment (or decre- 
ment) a counter each time the COUNT node is instanti- 
ated. 

DELAY nodes are nodes which impose a delay per- 
iod selected by the Domain Expert 101 each time the 
node is instantiated. 

The function of block 194 is illustrated by the flow- 
chart in FIO. 7 and is described below in more detail. 
Control then passes to block 196 which determines 
whether the name of the node is on the list (stack) of 
undefined nodes. If not, 197 returns control to the User 
Interface 104. Otherwise, 198 removes the name from 
the list of undefined nodes. Block 200 then updates all 
pointers to this node. The pointers are updated by find- 
ing all the defined nodes which have attributes pointing 
to this node and setting those attributes to the address of 
the current node. Finally, 202 transfers control back to 
step 152 of FIG. 5. 

The flow-chart in FIG. 7 illustrates how the Knowl- 
edge Acquisition module 104 assigns attributes to a 



the Domain Expert 101 whenever Add Node 156 is 30 knowledge node. Block 212 determines whether there 



selected. The first stack shows the node names for 
nodes which already exist. The second stack shows the 
node names for nodes which are pointed to by existing 
(defined) nodes but which have not yet been defined 
themselves. In this manner* the Domain Expert 101 35 
always has easy reference to nodes which must be de- 
fined. 

When Add Node procedure 156 is selected, the Do- 
main Expert 101 is presented with a list of node types at 



are more attributes of the current node type to assign. If 
not, 214 returns control to the function which called it. 
Otherwise, 216 gets the value of the next attribute from 
the Domain Expert 101 by, for example, displaying the 
name of the attribute and allowing the Domain Expert 
101 to type in the value at terminal 18. Block 218 then 
determines whether the value is a pointer to another 
node. If not, control returns to 212. Otherwise, 224 
determines whether the node pointed to (called "point- 



192 for the Domain Expert to select from among. Valid 40 ed-to") has been previously defined by checking the list 



node types for HYPOTHESIS TREE nodes in the 
present embodiment are: KS node, AND node and OR 
node. KS nodes (knowledge sources nodes) are OR 
nodes which are the first node of a knowledge source 
and serve to identify the knowledge source. AND 45 
nodes are satisfied when all children of the node are 
satisfied while OR nodes are satisfied when any one of 
the node's children is satisfied as would be expected 
applying convention rules of logic. Other types of nodes 
may be defined in other embodiments. 

For flow chart type nodes, valid node types in the 
present embodiment are: TEST node, CONCLUDE 
node, CALL node, CONFIRM node, FACT node, 
COUNT node, and DELAY node. Other types of 
nodes may be defined in other embodiments. 

TEST nodes are nodes which require a test to be 
performed by the user or network manager 24 to obtain 
information for the Expert System 10. All nodes subse- 
quent to a test node depend upon the outcome of the 
test node. 

CONCLUDE nodes are nodes which generally ter- 
minate a flow-chart and provide a solution to the lowest 
level hypothesis for which the current flow-chart is a 
leaf 

CALL nodes are nodes which point to HYFOTHE- 65 
SIS TREE nodes in other branches of the HYPOTHE- 
SIS TREE and are useful to reduce need for redundant 
.portions of HYPOTHESIS TREES. Thus, in addition 



of defined nodes. If so, 226 sets the attribute to the 
address of the "pointed-to" node and control goes to 
212. Otherwise, 228 sets the value of the attribute to nil. 
Block 230 then determines whether the "pointed-to" 
node is on the list of undefined nodes. If so, control 
returns to 212. Otherwise, 232 adds 4t pointed-to" to the 
list of undefined nodes and control returns to 212. The 
process proceeds as described above until a no answer is 
received at step 212 after which control passes back to 
the procedure that called it. 

The flow-chart in FIG. 8 illustrates User Interface 
104 operation after selection of Modify Node Informa- 
tion 158. First, 266 gets the name of the knowledge node 
the Domain Expert 101 wants to modify. It does so by, 
for example, displaying a list of the names of the defined 
nodes and allowing the Domain Expert 101 to select 
one. Control then passes to Block 267 where the type of 
. node is determined by the previously defined or existing 
node type. Block 268 then retrieves the remaining attri- 
60 butes of the node by invoking the Add Node procedure 
210 to allow the Domain Expert 101 to change any of 
the attributes except the node name and type. Ideally, 
the default values of the attributes are the original val- 
ues. This process is illustrated by FIG. 7 and explained 
above. Finally, 270 returns control to the User Interface 
by transferring control back to step 152 of FIG. 5. 

The flow-chart in FIG. 9 illustrates User Interface 
104 operation after selection of Modify Node Type 
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procedure 160. A separate procedure for modifying the 166, the User Interface 104 presents a graphical repre- 
knowledge node type is provided and not integrated sentation of the Expert Information Structure 111 while 
with the Modify Node Information procedure 158 in selection of Show Knowledge source 168 provides a 
the preferred embodiment. At step 284 the procedure text output of the defined nodes. In the Display Knowl- 
gets the name of the node to change the type of from the 5 edge Source procedure 166, the system displays, for 
Domain Expert 101. As before, for example, it might example, a diagram such as that in FIG. 12. The circles 
display a list of the names of defined nodes and allow (shown as ovals in the figure) represent nodes. Text 
the Domain Expert 101 to select one. Control then inside of or adjacent to the nodes are used to identify the 
passes to step 288 which gets the new node type from node or operation being displayed. In the example of 
the Domain Expert 101. It could do this by, for exam- 10 FIG. 12, the display shows a receive line failure (RLF) 
pie, displaying a list of the node types and allowing the for the example network of FIG. 1 with the associated 
Domain Expert 101 to select one. Control then goes to nodes. The diagram shows nodes as ovals with the node 
step 294 which calls the Get Node Attributes procedure names written in the ovals. The nodes pointed to by a 
210 to get the attributes (other than name and type) of node are drawn below the node and connected to it 
the node from the Domain Expert 101. Finally, 296 IS with a line with a link name associated with it In other 
transfers control to the main User Interface program at embodiments, the node names may be used to represent 
step 152. the nodes with lines interconnecting the names (i.e. no 

The flow-chart in FIG. 10 illustrates User Interface circles representing nodes). Similarly, the display may 
104 operation after selection of Delete Node Procedure flow left to right, etc., rather than top to bottom and 
162. First, 310 gets the name of the knowledge node to 20 information may be in symbolic or abbreviated form as 
delete from the Domain Expert 101 by, for example, required. 

displaying the names of defined nodes and allowing him The circle 366 represents the alarm node associated 
to select one. Second, 318 removes the name chosen with the knowledge base. The text in the circle is the 
from the list of defined knowledge nodes. A verification name of the node. Node 366 points to nodes 368, 370 
process may be included in this step to help assure that 25 and 372 which represent three possible causes of the 
nodes are not accidentally deleted. Block 320 then de- alarm. The lines connecting the nodes are indicated as 
termines whether any attributes of the other nodes point OR links indicating that any of these nodes alone could 
to the node. If not, 332 returns control to the User Inter- result in the RLF Alarm 366. 

face 104. Otherwise, 324 deletes all such attributes to For example, the node drawn as 366 is an OR node 
ensure that no nodes point to the deleted node. Finally, 30 names *'RLF Alarm" (RLF stands for Remote Line 
328 transfers control to 152. Failure) and written inside. The node is an OR node, 

The flow-chart in FIG. 11 illustrates User Interface meaning that its truth value is true if at least one of the 
104 operation after selection of Copy Node procedure nodes to which it points is true. It points to nodes named 
164. First, block 340 gets from the Domain Expert 101 p-to-p-remote-rlf, p-to-p-central-rlf and multidrop-cen- 
the name of the knowledge node to copy (called the 35 tral-rlf. These are represented as 368, 370 and 372. 
source) by, for example, displaying a list of the defined Each of the nodes 268, 370 and 372 may be further 
nodes and allowing him to select one. Second, 346 gets broken down into other OR or AND links as shown in 
from the Domain Expert 101 the name of the node to connection with node 370. Node 370 includes four 
which the information will be copied (called the target). nodes below it which are shown as OR functions mean- 
It might to this by requesting the Domain Expert 101 to 40 ing that node 370 is true if any one of these four nodes 
type a name, and accepting the name if there are no is true, namely; bad phone line node 374, bad remote 
existing defined nodes by that name. Third, 354 sets the 376, bad central 378 or transient phenomenon 380. Each 
values of the target attributes to the values of the corre- of these four nodes may point to other nodes or pro- 
sponding source attributes. Fourth, 355 calls the get cesses as illustrated by node 380 which points to a short 
node attributes function 210 to enable the Domain Ex- 45 process represented as a flow-chart. This flow-chart 
pert 101 to change the attributes of the target (except first determines if the central modem responds at 382 
node type). Block 356 then determines whether the and if so, an automatic test of DCD (Data Carrier De- 
name is on the list of undefined nodes. If not, 358 trans- tect) is performed at 384. If not a manual test of DCD is 
fers control to step 152 of FIG. 5. Otherwise, 360 re- indicated by step 386. 

moves the name of the target from a stack list main- 50 Display Knowledge Source procedure 166 may be 
tained by the system which keeps track of all undefined implemented in a conventional manner using the stan- 
nodes (the undefined stack list). Block 362 then updates dard drawing tools commercially available in the Ex- 
the pointers to the target. It does so by finding all the pert System Programming Environment 16 such as 
defined nodes which have attributes pointing to the those in Carnegie Group's Knowledge Craft tm prod- 
target and setting those attributes to the address of it. 55 uct or using known CAD (computer aided drafting 
Finally, 364 transfers control to step 152 of FIG, 5. techniques). The information for creating such a display 
This Copy Node procedure 164 is designed to facili- is readily available from the knowledge base 109 which 
tate data entry by allowing easy entry of data for new has information relating each of the nodes to each other 
nodes by in effect duplicating existing nodes. The attri- as well as the attributes of each node. This display capa- 
butes differing from the node being duplicated may then 60 bility provides the user or expert an easily grasped rep- 
be modified since the procedure automatically calls the resentation of what procedure is indicated by a particu- 
Get Node Attributes routine 210. Other such proce- lar alarm. 

dures for simplifying data entry when creating nodes The flow-chart in FIG. 13 illustrates User Interface 
will occur to those skilled in the art. 104 operation after selection of the Show Knowledge 

The User Interface provides two mechanisms for 65 Source procedure 166. Block 386 prints the list of de- 
displaying the knowledge source: Display Knowledge fined knowledge nodes of the currently loaded knowl- 
Source procedure 166 and Show Knowledge Source edge source to the terminal's display 18 (or to the 
procedure 168. Selection of Display Knowledge Source printer 20). Block 388 then similarly prints the list of 
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undefined nodes, that 'is, nodes which have been re- procedure 182. First, 470 clears a display window set up 
ferred to but which have not yet been defined. Finally, on the screen for the Bulletin Board Display in a con- 
390 transfers control back to step 152 of FIG. 5. vehtional manner. Next, 472 writes the name of each 

The flowchart in FIG. 14 illustrates User Interface goal on the Bulletin Board 120 along with its status and 
104 operation after selection of the Load Knowledge 5 priority. Goal status and priority are attributes associ- 
Source procedure 170. First, step 400 gets the name of ated with the goal which are used to determine the 
the knowledge source to load. Ii might do so by, for order of processing the particular goal as explained 
example, displaying a list of knowledge sources and previously. Block 474 then transfers control to step 152 
allowing the Domain Expert 101 to choose one. Next, of FIG. 5. 

402 loads the selected knowledge source into memory. 10 FIG. 21 illustrates the operation of the User Interface 
Finally, 404 transfers control back to 152 of FIG. 5. 104 after selection of the Resume procedure 184. This 

The procedure Update Alarm Map 171 fa used by the procedure is used to resume operation on a goal which 
Domain Expert 101 to update a map or table relating has been paused. A goal is assigned one of several status 
alarm type to knowledge sources. The present inven- states (as was described in more detail in connection 
Hon may use several knowledge sources broken up as 15 with FIG. 4) including "posted" indicating that the goal 
the Domain Expert 101 sees fit. In order to process an fa ready to run, "active" when the goal is actually being 
alarm, the alarm is first related to an appropriate kriowl- processed, "paused" when the goal has been paused by 
edge source by reference to this table. When the Do- the user in manual or semi-automatic mode, and "sus- 
mam Expert 101 wishes to add a new alarm or knowl- pended" when the goal has been running but has been 
edge source, he updates this table to properly relate the 20 temporarily stopped by the system in automatic or semi- 
alarm with the appropriate knowledge source. The automatic mode as when, for example, further informa- 
taMe may be updated using conventual table update tion U required to complete processing a goal. A typical 
"ri a i. _ • ttt*- -„ tt t — example is when a test, such as a loop-back test must be 

The flow-chart m FIG 15 Ululates User Interface patomed in order to proceed with processing the goal 
104 operation after selecuon of the Save Knowledge 25 ^cc. While this test is being performed, the goal is 
SETT?™ "3 fu«,blc<*410get S tiienameof placed m me ded aatuVwhfie the goal is sus- 
, E MVe by STS,** P«>ded, the ENDS 10 retrieves the next goal from the 

£L2 J^-H o£ Th ^ 2* BuUetin 120 for P"**^* 80 «*" system 

tEZ^^^f^^^^?^ « does no1 nave to OP™* m » completely sequential 

S.t S tnuS^ 

104 operation after selection of Clear Knowledge ^„^ M „,™.<.<.;.,„ „*,v. „„.,« i 

Source 174. Block 420 clears the current knowledge ^ ° f ^ „ . m 

source from memory, and 422 transfers control to 152 35 n^^Z^^X'^^^T 

first gets the name of the goal to resume. It does so by, 

3. System Operation for example, listing all paused goals and allowing the 

FIGS. 17 through 22 illustrate the operation of the EL'S f"*"*'*™™ ° f the 

system operation functions of the User Interface 104. 2rSL*S i F i • ^ • ! £ 

The Operator 128 uses the system operation functions 40 ™ ™ e , n 122 » »^ able the 

to set the operation of the ENDS lOto manual, semi- 'T^ " V™*™**> processing 

automatic oVautomatic mode, run ENDS, disphy the SLST"^ VflZ f^*^"*"^ 

Bulletin Board 120, resume inferencing paused goals f ™ letm ^d UO, , will be processed 

and exit ENDS 10 e first even though the 'resumed' goal was interrupted. 

The flowchart in FIG. 17 illustrates User Interface 45 j"* ! S *f C * nse *"* *<? h re?un ? ed b ? p,a< f g * 
104 operation after selection of the Change Test Mode S££^2?S q ^ C fo ' P roc ? t,a * A ?"*f ! s 
procedure 175. First, block 434 gets the mode of opera- ^f^' 6 oal * *? rt * 

tion by allowing the Domain Expert 101 to select from J""* ^\ the processmg is to re- 

manual, automatic or semi-autoimuic. The nature of the ™* ^ y teWt^&gtm. 
three modes has been explained previously. At step 436, 50 F ^ y \* 9 *, trans f ers ~ n,rol » «** *« ° f «°; * 
.globalvariablecdled^mode-faupdaJtorenectthe ^S^^^t^^^^J 01 ^ 
selection made in step 434. Finally, 438 returns control J°? B<te L ,e S c S 0 ? £ i lit™ 0 ?* 5 « ^ * 
to the User Interface 104 at step 152 of FIG. 5. **" fi °° ^ B ^ etm J 20 t0 * log at ' ™« ■?* of 

FIG. 18 illustrates the operation of the User Interface * ?. 1 X T* ? "% 

104 after selection of Run 178. Block 450 initializes the 55 f? y t w by ^ ot BI «* 512 

structures and variables used during operation of the tbm ,^ a ?*T™- T ° o PA raU0n 8 « am ' user 
system. Block 452 then invokes the Controller 112, mMSt mVokc Expert S y stem 10 
which schedules the modules of the system as illustrated 4. Sample Session (Manual Mode) 

in FIG. 2, The operation of the Controller 112 is de- * , - . . 

scribed in a laterlection. «0 .± ° r< ^ r " **? m*? ° f ^ T" 0 " ° f 

FIG. Willustratestheoperationofthe User Interface J" *f 2«« ™* » V^i' 8es ^ con - 

104 after selection of Run One 177. Block 456 initializes ?"?f? "? Manual , Mo ? e of °Pe™tion. Operator 
thestructuresand variables used during operation of the " p " " s £L m a ^£ Xt'S™ .^SLS" 16 ^ 
system. Block 458 then invokes the Controller to pro- from 4,16 Expert Systtm 10 15 $hown m bold - 
cess the next goal only. Finally, 460 transfers control to 65 TABLE 1 

Step 152 to FIG. 5. Simple Scaion 

FIG. 20 illustrates the operation of the User Interface An RLFdumtu, been received for centkal 

104 after selection of the Display Bulletin Board Status modem on » MULTIDROP line. 
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TABLE 1 -continued °* a com P^ ex data communications environment 

■ and will thus be used herein for instructional purposes. 

Sample Sc * fal The User Interface organizes the nodes defined by 

Thii tUnn may be c&used by: the Domain Expert into a data structure called ah Ex- 

iA^ppS^unit, 5 P crt Information Structure, such as that pictured in 

-A deflective diagnostics board. FIG. 24. The structure combines the simplicity and 

Testing for a Transient alarm condition. efficiency of flow-chart based knowledge representa- 

M J , .... tion with the hierarchical organization of hypothesis 

^ o?~)?es CUnWltly tree-based knowledge representation. 

10 The hypothesis tree is a hierarchical structure of 

dear this alarm and monitor the system for 2 minute* hypotheses, each of which IS associated With a symptom 

or possible failure. The structure is processed by using a 
(yes or nojya* ***** process of elimination among hypotheses. The Domain 

Expert creates such an Expert Information Structure 
The RLF Alarm is still present Continuing diagnositcst 15 based upon his expert knowledge of the workings of the 

Testing for an improperly strapped central unit system to be diagnosed. The Domain Expert may start 

Dot. the CENTRAL unit have hardware straps? ** P rOCCS * for by isolating each different 

(yes or no) yes type of malfunction (alarm) which must be analyzed. 

Begin checking central unit's DCD strapping. Each of these alarms, or certain groups of such alarms, 

20 may lend themselves to creation of an individual knowl- 

i^r^T' f ° r COn$hUDt 0007 edge sources. In FIG. 24, five such types of malfunction 

are shown (542, 544, 546, 547) explicitly and others 

A CENTRAL unit on a MULTIDROP line should always be suggested implicitly by the arrows leading from node 

strapped for switched DCD. 540. The Domain Expert may select any number of 

This CENTRAL on»t is improperly .trapped. Correct strapping. „ knowledge SOUTCCS to construct SO that the problem is 

broken down into a manageable size. He then constructs 

_ . T » . e . — a hypothesis tree for each type of malfunction and pro- 

Expert Information Structure ceeds tQ divjde ^ hy p 0thesis mt0 further hv . 

Because of the complexity of data communication pothesis (e.g. 548, 549, 550) until a leaf in the hypothesis 
network diagnostics, it may be easier to understand the 30 tree is reached. At he leaf, there may be questions to be 
Expert Information Structure 111 with an example from answered or test procedures to be followed. The hy- 
a more familiar subject. FIG. 23 therefore illustrates a pothesis tree then converts to a flow-chart format (e.g. 
block diagram of a possible use of the structure for an 562 down, 551 down) in order to obtain the needed 
automobile diagnostic system. This example system information. Such flow-chart operations may call other 
includes three hypothetical diagnostic machines, each 35 flow-charts or other hypothesis tree nodes in the same 
of which is connected to an automobile which is the (or another) hypothesis tree in order to satisfy the hy- 
diagnostic target for this example. Diagnostic Machine pothesis. This hybrid of the hypothesis tree and the 
A 514 is connected to automobile A 516 via connection flow-chart is referred to herein as the Expert Infonna- 
517. Diagnostic Machine B 518 is connected to automo- tion Structure or the Structured Flow Graph. Each 
bile B 520 via connection 522. Diagnostic Machine C 40 knowledge source so constructed is related to the par- 
524 is connected to automobile C 526 via connection ticular type of alarm through a knowledge source table. 
528. Each of the three diagnostic machines is then con- At the top of the tree of FIG. 24 is a root node 540 
nected to the Expert Auto Diagnostic System 530 via which is pointed to by no other knowledge nodes. The 
connections 532, 534 and 536 respectively which may, root node 540 points to nodes such as 542, 544, 546 and 
for example be wireless radio links in this hypothetical 45 547. representing all possible alarms. The latter nodes 
case. Each diagnostic machine monitors the operation represent the high level hypotheses. These are con- 
of the car it is connected to and sends an alarm to the firmed or rejected by first decomposing them into "sub- 
Expert Auto Diagnostic System 530 upon discovering a hypothesis", which are represented by the knowledge 
problem. This hypothetical network has similarities to nodes pointed to by each alarm. Each of these nodes in 
the network diagnostic environment in that there are 50 turn may point to nodes representing the sub-hypothesis 
certain tests which should not be invoked automatically which could have caused it. The pattern can continue 
except when certain conditions prevail. For example, it until the hypotheses can be most easily confirmed or 
might be dangerous to invoke certain brake tests or eliminated by the answer to a question asked by the 
transmission tests at highway speeds without the driv- user, the response to a test sent to the Network Test 
er's consent. A set of criteria could be developed for 55 Manager or the application of deterministic, procedure- 
this example which would dictate the ability of the oriented testing processes which may include gathering 
diagnostic system to automatically initiate tests. These information from the user or a device analogous to the 
hypothetical diagnostic machines are assumed to have Network Manager. Such processes are represented by 
the capability of performing tests on the car and cor- flow-charts. 

recting certain problems subject to such constraints. 60 In other words, the root node 540 represents the most 

FIG. 24 shows an Expert Information Structure for general malfunction: that there has been a malfunction, 

the Expert auto Diagnostic System 530. The informa- Leaves represent the more specific malfunctions. The 

tion in the Example is for instruction as to the operation system uses the structure for reasoning as follows. Upon 

of the expert information structure only. It should be receiving ah alarm, the system processes the sub-tree 

noted that this is an overly simplified contrived example 65 having the node associated with the alarm as its root 

and is not necessarily an accurate diagnostic procedure The goal of the system is then to determine the nature of 

for troubleshooting an automobile radiator. It is none- the problem and then to resolve the problem. Each 

theless an easier environment for many to grasp than alarm node points to the possible causes of the associ- 
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ftted alarm. The system determines whether each cause 
occurred by determining whether the nodes that the 
node points to has occurred. This pattern continues 
through all branches and leaves of the tree. Whether a 
malfunction/resolution at the leaf level occurred is 5 
determined by carrying out the procedures in the flow- 
chart to which the leaf points. 

In the example of FIG. 24, the Expert Information 
Structure has one root node 540 which points to knowl- 
edge nodes which represent every possible alarm 10 
(called alarm nodes). This node is automatically defined 
by the system when the domain expert defines the alarm 
nodes. The alarm nodes in the example are Won't Start 
542, Stalls 544, Overheats 546 and Power Loss 547. 
Each alarm node in turn points to nodes representing IS 
the malfunctions which could have caused the alarm. In 
the example, Overheats 546 points to nodes represent- 
ing all of the possible causes of an engine overheating. 
This example presumes that only three such possibilities 
exist as shown in FIG. 34. Radiator Leaks 548 repre- 20 
sents a leaking radiator, Coolant Low 549 indicates that 
the radiator is low on coolant and Bad Thermostat 550 
represents a malfunctioning thermostat. 

Any one of these problems could cause a car to over- 
heat. A Domain Expert therefore would use the User 25 
Interface to define overheats 546 as an OR node, which 
means that it occurred if at least one of the nodes it 
points to occurred. OR nodes have the following attri- 
butes: IS-A, NODE-ID, DUE-TO-CONDITIONS, 
YES-NODE, PRErDESCRIPTION, QUERY, HAS- 30 
TEST, CONCLUSION-IF-TRUE, CONCLUSION- 
IF-FALSE, FORGET, and HELP. 

The attributes YES-NODE, QUERY, HAS-TEST, 
FORGET and HELP have no purpose in an alarm node 
of the preferred embodiment and will be explained be- 35 
low. For all node types, the attribute IS-A contains the 
node type. All knowledge node types for the present 
embodiment have been previously discussed. For OR 
nodes, this will be "OR node". For all node types, 
NODE-ID contains the name of the node. For Over- 40 
heat node 546, this would be "Overheats". DUE- 
TO-OR-NODE contains the names of the nodes from 
which the truth value of this node 546 is determined. In 
the example, Overheats 546 will be true if one of the 
nodes radiator-leaks 568, coolant-low 549, or bad-ther- 45 
mostat 550 occurred (in this example, we assume that 
these are the only, possible causes of overheating). 
DUE-TO-CONDITIONS contains the node names in 
DUE-TO-OR-NODES, each followed by either "yes" 
or "no". The value after each node name indicates 50 
whether to consider that node to be true of the problem 
associated occurred ("yes") or did not occur ("no"). In 
the example, the attribute would contain "(radiator- 
leaks yet) (coolant-low yes) (bad-thermostat yes)" 
Therefore, the node 546 will be true if either radiator- 55 
leaks, or coolant-low or bad-thermostat nodes is true. 

For all knowledge node types, PRE-DESCRIP- 
TION contains the message to be printed upon reaching 
the node. PRE-DESCRIPTION enables the user to see 
what ENDS is doing, and assists the Domain expert in 60 
debugging. The PRE-DESCRIPTION in Overheats 
546 could contain the message "Car overheated. Either 
the radiator leaks, the coolant is low or the thermostat 
is bad." 

For all knowledge node types, CONCLUSION-IF- 65 
TRUE 562 contains the message to be printed upon 
determining that the node is true and CONCLUSION^ 
IF-FALSE 566 contains the message to be printed upon 
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determining that node 549 is false. One purpose of 
CONCLUSION-IF-TRUE and CONCLUSION-IF- 
FALSE is to enable the user to track the progress of 
ENDS and to assist the domain expert to debugging, 
Overheat probably would contain no message in CON- 
CLUSION-IF-TRUE or CONCLUSION-IF-FALSE 
because the truth value of an alarm node is known. 

For all knowledge node types, FORGET controls 
whether the node .546 will be processed if its truth value 
has already been determined. For example, if 546 were 
pointed to by more than one node, FORGET would 
determine whether ENDS would process 546 a second 
time to determine its value. The value of FORGET in 
Overheat 546 would be inconsequential because the 
node 546 is pointed to only once, by Overheats 546. 

Table 2 below summarizes the attributes of the Over- 
heats node 546: 

' TABLE 2 

ATTRIBUTES OF "OVERHEATS" 



IS-A 

NODE-ID 

DUE-TO-OR-NODE 
DUE-TO-CONDITIONS 



YES-NODE 
PRE-DESCRIPTION 



QUERY 
HAS-TEST 

CONCLUSION IF TRUE 
CONCLUSION IF FALSE 
FORGET 
HELP 



or node 
overheats 

(ndlator-leaks. coolmMow, bad- 
thermostat) 
(radiator-teaks yes) 
(coolant-low yes) 
(bad -thermostat yes) 

"Car overheated. Either the 
radiator leaks, the coolant is 
low or the thermostat is bad." 



The first knowledge node pointed to by Overheat 546 
is Radiator-leaks 548. Because it points to no other 
knowledge tree node, it is a leaf node. Because all leaf 
nodes are OR nodes in this embodiment, the Domain 
Expert would use the User Interface to define Radiator- 
leaks as an OR node. He would set the attributes as 
follows. DUE-TO-OR-NODE and DUE-TO-CONDI- 
TIONS would be empty because the node 548 points to 
no other nodes. YES-NODE is the first node of the 
flow-chart to which a leaf node might point Radiator- 
leaks 548 points to a flow-chart with procedures to 
determine whether the radiator leaks. If so, the proce- 
dures repair the leak and determine whether the radia- 
tor needs coolant. If so, the procedures add coolant. 
YES-NODE therefore contains Is-radiator-leaking, the 
first node in that flow-chart PRE-DESCRIPTION 
might contain "Current hypothesis: radiator leaks*'. The 
attributes QUERY and HAS-TEST apply only to leaf 
codes which do not point to flow-charts and will be 
explained below. CONCLUSION-IF-TRUE could 
contain "Radiator leak repaired". CONCLUSION-IF- 
FALSE would contain "Radiator was not leaking'*. 
The value of FORGET here would be inconsequential, 
because the node 548 is only called once. 

Hie HELP attribute contains nothing in this case 
since'the user is not prompted for a test result If pres- 
ent, the HELP attribute can be used in a number of 
different ways as desired by the system designer. For 
example, the HELP attribute can be used as a pointer to 
or file name of a help file which contains information 
which is context sensitive. This help file may contain, 
for example, text or graphical assistance to the user or 
may place the user within a network map showing the 
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network surrounding the location of an alarm so that 
the operator can get a better idea of what type of prob- 
lems is being encountered and the ramifications of such 
problems to allow the operator to make better informed 
decisions regarding corrective actions. Those skilled in 
the art will appreciate that many possible implementa- 
tions are possible for use of the HELP attribute. 

The attributes of node 548 (radiator leaks) are sum- 
marized in Table 3 below. 

TABLE 3 

ATTRIBUTES OF "RADIATOR- LEAKS" 



10 



IS-A 

NODE-ID 

DUE-TOOR-NODE 
DUE-TO-CONDITIONS 
YES-NODE 
FRE-DESCRIPTION 

QUERY 
HAS-TEST 

CONCLUSION IF TRUE 
CONCLUSION IF FALSE 
FORGET 
HELP 



OR node 
ndutar*leak5 



tft-radistor4eaking 
"Current hypothesis: 
radii tor leaks." 



"radiator leak repaired" 
"radiator was not leaking" 



IS 
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low. The answer to the question will be the equivalent 
to the response to the HAS TEST test 

CONCLUSION-IF-TRUE and CONCLUSION-IF- 
FALSE in Is-radiator leaking would contain appropri- 
ate messages to the user. Because Is-radiator-leaking is 
pointed to only by Radiator-leaks. FORGET would be 
inconsequential. 

HELP contains the message to print if the user re- 
quests help while this node 551 is being processed. Help 
messages are therefore used only in nodes which have a 
QUERY. For Is-radiator-leaking, HELP count contain 
"While car is running, look for dripping coolant*'. 

If the user or diagnostic computer returned "false" in 
response to being asked whether the radiator leaked, 
control would go to Confirm-no-leak 552, a CONFIRM 
node which returns the flow of control to Radiator" 
leaks 548 with a value of 'false**. CONFIRM nodes 
contain the following attributes: IS-A, NODE-ID, 
BRANCH-TO-AND-CONFIRM, NEXT- 
HYPOTHESIS, NODE-HA VINO-HYPOTHESIS, 
and PRE-DESCRIPTION. BRANCH-TO-AND- 
CONFIRM contains the name of the node to return 
control and a truth value to. Normally this is the leaf 
node which called the flow-chart of which the confirm 
node is a member. For Confirm-no-leak, BRANCH- 
TO-AND-CONFIRM contains "Radiator-leaks no*'. 
This is illustrated in Table 5 below: 

TABLE 5 

ATTRIBUTES OF "CONFIRM-NO-LEAK" 



Radiator-leaks points to the flow-chart beginning 25 
with knowledge node Is-radiator-leaking 551. Is-radia- 
tor-leaking is a TEST node because the subsequent 
flow-chart instruction depends on the answer to a ques- 
tion sent to the user or the Diagnostic Machine. Test 
nodes have attributes IS-A, NODE-ID, YES-NODE, 30 
NO-NODE, HAS-TEST, PRE-DESCRIPTION, 
QUERY, CONCLUSION-IF-TRUE, CONCLU- 
SION-IF-FALSE, FORGET and HELP. YES-NODE 
contains the name of the node to branch to if the answer 
to the question is yes. For Is-radiator-leaking, YES- 35 

NODE is Find-leak. NO-NODE contains the name of 

the node to branch to if the answer to the question is no. 

The FORGET attribute is used when the node may be NEXT-HYPOTHESIS attribute allows the Domain 
pointed to during more than one analysis. IF the infor- Expert to change the hypothesis to the process follow- 

TZ^r*™ 25 22? £H* S* 40 * * is ^wledSe -de. By default, the system will 

continue processing the tree in the nodes in the order 



IS-A: 

NODE-ID; 

BRANCH-TO-AND-CONFIRM : 
NEXT-HYPOTHESIS: 
NODE-HA VING-HYPOTHESIS 
PRE-DESCRIPTION: 



confirm node 
confirm-no-leak 
(radiator-leaks no) 



generally, to re-test and FORGET = "no". If the infor- 
mation is more dynamic or volatile, then it should be 
re-tested whenever the test node is encountered an 
FORGET = "yes**. For Is-radiator-leaking, NO-NODE 
is Confirm-no-leak. Table 4 below shows the attributes 45 
of is-radiator-leaking: 

TABLE 4 



ATTRIBUTES OF "IS-RADIATOR-LEAKING'* 



IS-A 

NODE-ID 

YES-NODE 

NO-NODE 

QUERY 

HAS-TEST 

PRE-DESCRIPTION: 

CONCLUSION-IF-TRUE: 

CONCLUS10N.IF.FAI.SE: 

FORGET: 

HELP: 



test-node 

is-radiator-leaking 

find-leak 

confirm-no-leak 

"is radiator leaking?" 

"check radiator!" 
"radiator is leaking" 
"radiator is ok" 
yes 

"while car is running, look for 
dripping coolant" 



50 



originally specified. The originally specified order is the 
order the Domain Expert listed the nodes in the DUE- 
TO-AND-NODE or DUE-TO-OR-NODE attribute of 
the node which points to them. If reaching the CON- 
FIRM node means that certain information has been 
learned that would make a different processing order 
more effective, the Domain Expert can specify a new 
order here by listing the node names in the desired 
order of a group of nodes all pointed to by the node 
contained in NODE-HA VING-HYPOTHESIS. 
Reaching CONFIRM-NO-LEAK, would not indicate 
any reason to change the processing order. Accord- 
55 ingty, NEXT-HYPOTHESIS and NODE-HAVING- 
HYPOTHESIS would contain "nil". 

If on the other hand the user or diagnostic computer 
returned "true" in response to being asked whether-the 
radiator leaked, control would go to Find-leak 554, a 
60 TEST node which sends an instruction to the diagnostic 
machine (in automatic mode) or the user (in manual 
mode) to locate the leak. For Find-leak 554, HAS- 
TEST would contain the name of a function to send the 
diagnostic machine to locate the leak and QUERY 



HAS-TEST is the name of the test to send to the 
Diagnostic Machine if the system is operating in the 
automatic mode. Automatic mode and manual mode are 
explained below (see Inference Engine). For Is-radia- 
tor-leaking, HAS-TEST would be a test to physically 6$ would contain text instructing the user to locate the 
check the radiator for leaks. leak. Any value returned by the machine or user would 

QUERY contains the question to print to the user if be disregarded. Both YES-NODE and NO^NODE 
the system is operating in manual mode, explained be- would contain Plug-leak. 
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Plug-leak 556 is a TEST-NODE which instructs the 
machine (in automatic mode) or the user (in manual 
mode) to repair the leak. The HAS-TEST attribute 
would be the name of a function to send to the the 
diagnostic machine instructing it to repair the leak. 
QUERY would contain an instruction to the user to. 
repair the leak. Any response from the machine or user 
would be disregarded. YES-NODE and NO-NODE, 
would contain "Call-coolant-low". 
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For Conclude-radiator-leaks, the message might be 
"Lead repaired." 

Coolant-low 549 is the second node to which Over- 
heats 546 points. Because it is a leaf node, it is defined as 
an OR node. Because Coolant-low points to a flow- 
chart, QUERY, HAS-TEST and HELP contains "nil". 
YES-NODE contains the name of the first node in the 
flow-chart: Is-coolant-low. FORGET contains **no" so 
that after Coolant-low is called from Call-coolant-low 



The call-coolant-low node 558 calls the How-chart 10 558 » thc value of Coolant-low 549 is retained and the 



pointed to by the leaf node coolant low 549, described 
below, to determine whether the radiator needs coolant, 
and, if so, to add coolant. A CALL node contains attri- 
butes: IS-A, NODE-ID, CALL-FUNCTION, FUNC- 
TION-CONDITION, PRE-DESOUPTION, CON- 
CLUSIONEF-TRUE, CONCLUSION-IF-FALSE, 
YES-NODE, NO-NODE and FORGET. IS A, 
NODE-ID, PRE-DESCRIPTION, CONCLUSION- 
IF-TRUE, CONCLUSION-IF-FALSE are described 
above. For Call-coolant-low, IS-A contains call-node, 
node-id contains call-coolant-low; PRE-DESCRIP- 
TION, CONCLUSION-IF-TRUE and CONCLU- 
SION-IF-FALSE contain appropriate messages; and 



flow-chart is not processed a second time. 

Is-coolant-low is a test node to determine whether 
coolant needs to be added to the radiator. HAS-TEST 
contains the name of a procedure for the diagnostic 
15 machine to perform to determine whether the coolant is 
low. QUERY contains a message requesting the user to 
determine whether the coolant is low. NO-NODE con- 
tains "Confirm-coolant-not-low", the name of node 564. 
YES-NODE contains "Add-coolant", the name of node 
20 566. 

If the value of Is-coolant-low is **no", control goes to 
confirm -coolant-not-low 564, which returns control to 
Coolant-low 549 with a value of "no". Confinn-coo- 



the attributes of this node: 

TABLE 6 

ATTRIBUTES OF "CALL-COOLANT-LOW" 



fAr»«i ««w w-i ♦ • -i T vi ~ c u i ' lant-not-low 564 is a CONFIRM node with BRANCH- 

forget and help^contam ml. Table 6 below summarizes 25 TO-AND-CONFIRM containing "(Coolant-low no)" 

and NEXT-HYPOTHESIS, and NODE-HAVING- 
HYPOTHESIS containing "nil". 

If on the other hand the value of Is-coolant-low is 
"yes", control goes to Add-coolant, a TEST node with 
30 QUERY instructing the user to add coolant and HAS- 
TEST instructing the diagnostic machine to add cool- 
ant Add-coolant ignores the response from the user or 
machine. Accordingly, both YES-NODE and NO- 
NODE contain "Confirm-coolant-low", the name of 
35 node 568. 

Ctonfirm-coolant-low 568 then returns control to 
Coolant-low 549 with a value of "yes". Confirm-coo- 
lant-low is a CONFIRM node with BRANCH- 
TO-AND-CONF1RM containing "(Coolant-low yes)" 
40 and NEXT-HYPOTHESIS and NODE-HAVING- 
HYPOTHESIS containing "nil". 

If the value of Coolant-low 549 was found to be 
"yes", the goal has been solved and the Inference En- 
gine returns control to the Controller. Otherwise, AND 



IS-A 

NODE-ID 

CALUFUNCTION 

FUNCTION-CONDITION 

PRE-DESCRIPTION 

CONCLUSION-IF-TRUE 

CONCLUSION-IF-FALSE 

YES-NODE 

NO-NODE 

FORGET: 

HELP: 



call-node 
call-coolant-low 
coolant-low 
(coolant-low yes) 
"check coolant level" 
"coolant level is low" 
"coolant level is ok'* 
conclude-radiator-leaks 
conclude-radiator-leaks 



CALL-FUNCTION contains the name of a hypothe- 
sis tree node, an "AND" node or an "OR node. Control 
will be transferred to the hypothesis tree node being 
called, and any hypothesis tree or flow-charts that 



would have been performed upon reaching the called M . . „ . , . ern . A . . «■ 

node will be performed currently. Then, control will 45 1°*' B«Wtemortat 550 becomes the hypothesis. The 

hypothesis, that the thermostat has malfunctioned, is 
true if the engine is warm, signified by Engine-warm 
570 and the thermostat is closed, signified by Thermo- 
stat closed 572. AND nodes have the following attri- 
50 butes: IS-A, NODE-ID, DUE-TO-AND-NODE, 
DUE-TO-CONDITIONS, PRE-DESCRIPTION, 
CONCLUSION-IF-TRUE, CONCLUSION-IF- 
FALSE, and FORGET. IS-A, NODE-ID, PRE- 
DESCRIPTION, CONCLUSION-IF-TRUE, CON- 



return to the call node with the value determined for the 
node being called. For Call-coolant-low, CALL- 
FUNCTION will be "coolant-low", the name of node 
549. 

FUNCTION-CONDITION contains the name of the 
node contained in CALL-FUNCTION followed by 
either "yes" to indicate that the CALL node is true if 
the node called returns true, or "no" to indicate that the 



CALL node is true if the ^ 35 CLUSION-IF-FALSE and FORGET are described 



false. For Call-coolant-low, FUNCTION-CONDI 
TTON is: "(coolant-low yes)". 

PRE-DESCRIPTION, CONCLUSION-IF-TRUE 
and CONCLUSION-IF-FALSE contain appropriate 
messages for the user. 

Both YES-NODE and NO-NODE contain "Con- 
clude-radiator-leaks", the name of node 560. 

The Conclude-radiator-leaks node 560 prints an ap- 
propriate message to the user and ends the reasoning for 
the Overheat node 546. CONCLUDE nodes contain 65 
the attributes NODE-ID and CONCLUSION. For all 
CONCLUDE nodes, NODE-ID contains conclude- 
node. CONCLUSION contains a message for the user. 



above. 

DUE-TO-NODE contains the names of the nodes 
from which the value of the AND node is determined. 
An AND node is **yes" if each node named in DUE- 
60 TO-AND-NODE occurred. In Bad-thermostat there- 
fore, DUE-TO-AND-NODE would contain "(Engine- 
warm) (Thermostat-closed)"; 

DUE-TO-CONDITIONS contains the knowledge 
node names in DUE-TO-AND-NODE each followed 
by either "yes" or "no". The value after each node 
name indicates whether to consider that node to be true 
if the problem associated occurred ("yes") or did not 
occur ("no"). In Bad-thermostat therefore, DUE-TO- 
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CONDITIONS would contain 
(Thermostat-closed yes)". 

In the example, the diagnostic machine cannot repair 
a bad thermostat. Therefore, CONCLUSION-IF- 
TRUE instructs the user what to do if the thermostat 
has malfunctioned. An informative CONCLUSION- 
IF-TRUE for Bad-thermostat would be "Thermostat 
malfunctioned and must be replaced." Table 7 below 
summarizes the attributes of the "Bad Thermostat". 

TABLE 7 
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ATTRIBUTES OF "BAD THERMOSTAT' 



IS-A: 

NODE-ID: 

DUE-TO*AND*NODE 
DUE-TO-CONDITIONS: 

PRE-DESCRIFTION 

CONCLUSION-IF-TRUE 

CONCLUSION-1F-FALSE 
FORGET: 



AND node 
bad- thermos tat 

(engine- warm, thcnnosut-closed) 
(engine-warm yes) (thermostat* 
closed yea) 

•'current hypothesis: bad 
thermostat*' 

"thermostat is malfunctioning and 
must be replaced 1 ' 
"good thermostat** 



The first requirement for determining Bad-thermostat 
550 true is finding Engine-warm 570 true. Engine-warm 
570 is an OR node which is true if the engine tempera- 
ture is above a certain level. Because 570 is a leaf node, 
DUE-TO-OR-NODE and DUE-TO-CONDITIONS 
contain 'Mil". Because 570 points to no flow-chart, 



would be processed after determining that a central 
network object with a point to point configuration has 
sent a receive line failure alarm to the Network Man- 
ager 24. P-to-p-central-rlf 600 is an OR node which 
represents that state of knowledge. 

The first hypothesis of the cause of the malfunction is 
a transient condition, represented by OR node Tran- 
sient €02. To determine whether this was the cause, 
TEST node 608 determines whether the central device 
responds to diagnostic information. If so, TEST node 
609 sends a test to the central object (OR, if in manual 
mode, instructs the user to send such a test) to deter- 
mined whether the central Data C arrier Detect (DCD) 
is on. If the result is positive, CONFIRM node CON- 
15 FIRM-TRANSIENT 612 returns "yes" to OR node 
Transient 602. If the test result if negative, CONFIRM 
node CONFIRM-NOT-TRANSIENT 614 returns 
"no" to OR node Transient 602 hypothesis. 
If 608 determines that the central object does not 
20 respond to diagnostic information, TEST node 616 
instructs the user to manually determine whether the 
central DCD is on. If the user answers "yes", 612 re- 
turns "yes" to OR node Transient 602. Otherwise, 614 
returns "no" to OR node Transient 602 hypothesis. 
25 The second hypothesis of the cause of the point to 
point central remote line failure is a malfunctioning 
receiver (demodulator) on the central object, repre- 
sented by Bad-central-receive hypothesis 617. To deter- 
mine whether this was the cause, TEST node 618 first 



YES-NODE contains "nil". The truth of 570 is deter- 
mined by the answer to the question in QUERY or the 30 deterrnines whether the central modem responds to 
response to the test in HAS-TEST. Table 8 below sum- 
marizes the attributes of the "Engine Warm" node: 

TABLE 8 



diagnostic information. If so, TEST node 620 sends a 
self test command to the central object initiating a self 



ATTRIBUTES OF "ENGINE WARM" 



IS-A 

NODE-ID 

DUE-TO-OR-NODES 
DUE-TO-CONDITIONS 
YES-NODE 
PRE-DESCRIPTION 

HAS TEST: 
QUERY 

CONCLUSION-IF-TRUE 

CONCLUSION-IF-FALSE 

FORGET: 

HELP: 



OR node 
engine-warm 



"current hypothesis: engine is 
warm" 

engine temperature above 
normal" 

"engine is warm" 

"engine temperature is normal" 



The second requirement for determining Bad-ther- 
mostat is finding Thermostat-closed 572 true. Thermo- 
stat-closed is an OR node which is true if the thermostat 50 
is in the closed position, not allowing water to flow 
through it. Like Engine-warm 570, Thermostat-closed 
is a leaf which points to no flow-chart, and thus attri- 
butes DUE-TO-OR-NODE, DUE-TO-CONDI- 
TIONS and YES-NODE contain "nil". The truth of 55 
572 is determined by the answer to the question in 
QUERY or the response to the test in HAS-TEST. 

If Bad-thermostat is true, control is returned to the 
Controller. Otherwise, the Inference Engine would 
continue to process remaining hypotheses pointed to by 60 
Overheats 546 (not shown in the example) until one was 
found true or until there were no more. 

Returning now to the network diagnostic environ- 
ment of the preferred embodiment, FIGS. 25 and 26 
show an example of a section of the Expert Information 65 
Structure for a data communications network as illus- 
trated by the example of FIG. 1. The figures show only 
the section of an Expert Information Structure 111 that 



test of the central object If the object fails the test, 
CONFIRM node 622 returns "yes" to Bad-central re- 
ceive 617. If the object passes the test, CONFIRM node 
624 returns "no" to Bad-central-receive 617. If 618 
determined that the central modem does not respond, 
626 instructs the user to manually self test the central 
object. If the object fails, 622 returns 4t yes" to Bad-cen- 
tral-receive 617. Otherwise, 624 returns "no" to Bad- 
central-receive 617. 

The third hypothesized cause of the point to point 
central remote line failure is a malfunctioning transmit- 
ter on the remote object, represented by Bad-remote- 
transmit 628. To determine if this was the cause, TEST 
node 630 first determines whether the remote object 
responds. If so, 632 sends a Transmit Level (TXL) test 
to the remote object. If the object passes the test, 634 
sends a self test to the remote object. If the object fails 
the self test, 638 returns "yes" to Bad-remote-transmit 
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628. If the object passes the self test, 638 returns "no" to 708 then invokes the Network Test Manager 124 to 
Bad-remote-transmit 628. handle any requests by the Inference Engine 122 for 

If the remote object fails the Transmit Level (TXL) information from the Network Manager 24. Fifth, 710 
test in 632, 640 determines whether the object is soft invokes the Network Configuration Manager 108 to 
strapped (i.e. configuration strapping information is 5 update the Network Structure Knowledge Base 110 if 
stored in a memory rather than physical hardware the Network Manager 24 has detected any changes in 
jumpers). If not, 642 instructs the user to manually re* the layout of the network since the last time the Net- 
strap the object. Otherwise, 646 reloads the Transmit work Configuration Manager 108 was invoked. Sixth, 
Level (TXL) strap. After 642 or 646, control goes to 712 determines whether the Controller 112 was initiated 
634, explained above. .10 with the command "Run One". If so, 714 transfers con- 

If the remote does not respond in 630, 648 instructs trol to 152 of the User Interface so that only one goal is 
the user to manually test the Transmit Level (TXL) on operated upon. Otherwise, 716 determines whether the 
the remote object If the object passes, 650 instructs the user has selected the command "Exit" from the User 
user to manually self-test the object Otherwise, 652 Interface. If so, 714 transfers control to step 718 where 
instruct the user to manually re-strap the object before 13 the process halts. Otherwise, control returns to 702 
performing a manual remote self test in 650. where the process is repeated until the user selects 

If the object passes the test un 650, 636 returns "no" "Exit". Some rearrangement of the Order of operation 
to Bad-remote-transmit 628. Otherwise, 638 returns of the controller 112 may be possible without departing 
"yes" to Bad-remote-transmit 628. from the present invention. 

The fourth hypothesized cause of the point to point 20 
remote line failure is a bad phone line, represented by Event Manager 

OR node Bad-phone-line 648. This must be the cause of The Event Manager 117 is invoked by the Controller 
the malfunction if none of the other three hypotheses 112 to send network tests to and receive alarms, infor- 
occurred. This hypothesis is assumed to be correct by mation events and network configuration events from 
the process of elimination of the other three causes. 25 the Network Manager 24. FIG, 27 shows how the 
Therefore the node attributes DUE-TO-OR-NODE, Event Manager 117 retrieves events (alarms, configura- 
DUE-TO-CONDITIONS, YES-NODE, QUERY, tion events and result events) from the Network Man- 
HAS-TEST and CONCLUSION-IF-FALSE contain ager 24. After the start block 726, 728 determines 
"nil". CONCLUSION-IF-TRUE contains a message to whether the Network Manager 24 has any events which 
the user, for example to inform the telephone company 30 the Event Manager 117 has not already retrieved. If not, 
of the malfunctioning line. 730 transfers control to 704 of the Controller 112 flow- 

r „ chart of FIG. 26. Otherwise, 732 retrieves the next 

controller cvent ffom ^ Network Manager 24. For each event, 

FIG. 26 illustrates the operation of the Controller block 734 then decodes the event to determine its type 
112. User Interface 104 commands "Run" and "Run 35 (alarm, configuration event or result event) and several 
One" initiate the Controller 112. If "Run One" is se- other characteristics including the time it was received 
lected, the Controller 112 only operates for one cycle by the Network Manager 24, and the network compo- 
on the goal which is next in the queue. First, after the hent it concerns. Next 736 constructs a record of the 
Start block 700, 702 invokes the Event Manager 117 to proper type (alarm, configuration or response) with the 
send network tests to and receive alarms, information 40 other above characteristics as its attributes. Block 738 
events and network configuration events from the Net- then determines whether the event is an alarm. If so, 739 
work Manager 24, since the last time it was invoked. sets the priority attribute of the record based on the 

Second, 704 invokes the Alarm Filter 118 to post alarm type. Block 740 then adds the alarm record to the 
non-redundant alarms as goals on the Bulletin Board Alarm Queue 114. Otherwise, 742 determines whether 
120. Third, 705 selects the next goal to solve. It does so 45 the event is a configuration event. If so, 744 adds it to 
by selecting the the goal with a status of "posted" and the Configuration Queue 113. If it is not an alarm or a 
priority at least as high as any other posted goal. If more configuration event, it must be a response event. In that 
than one posted goal has the highest priority, the Con- case, block 746 adds the record to the Response Queue 
troller 112 selects the goal which has been on the Bulle- 116. After 740, 744 or 746 adds the record to the proper 
tin Board 120 the longest or was generated earliest in 50 queue, 748 returns control to 728 where the process 
the preferred embodiment. In another embodiment, the begins to repeat 

most recent goal is selected depending upon the nature FIG. 28 shows an example of part of an Alarm Queue 
of the diagnostic system. Status, priority and time 114. Alarm record 770 points to the alarm queue 114. 
posted are goal attributes which are more fully ex- The Alarm Queue 114 points to a queue of alarm re- 
plained in the Inference Engine 122 section, but basi- 55 cords. Records 772 and 774 are examples of alarm re- 
cally, the status is an attribute which indicates whether cords. The alarm records contain information about the 
or not the goal is posted on the Bulletin Board 120 (for alarm including a unique identifier of the alarm record 
purposes of the present discussion). The priority is a (id), the type of alarm. Each Knowledge Source (ks) 
number assigned by the Domain Expert 101 to the type corresponds to an alarm, the name of the object which 
of goal indicating its importance, for example a number 60 sent the alarm (object-id), the time the Network Man- 
between 0 and 10 (or 0 and 100, etc) may be assigned. ager 24 received the alarm (time-received), the priority 
The time posted is, of course, used to determine how of the alarm (priority), the status of the alarm (status) 
long the goal has been posted in order to resolve the and the last record processed before the goal was sus- 
situation where two or more goals are posted with the pended (suspended-goal) The values of Id, Knowledge 
same priority. 65 Source, object-id, time-received are determined by the 

Fourth, 706 invokes the Inference Engine 122 to information in the alarm event. The value of priority is 
determine the problems which caused the goals on the determined by, for example, a table of each type of 
Bulletin Board 120 and to resolve the problems. Fifth, alarm and its corresponding priority which would be 
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assigned by the Domain Expert 101 based upon his type attribute. Block 852 determines the object which 

experience with what types of alarms demand the most sent.the alarm from the object-id attribute of the record, 

attention, priority communication links, policy, etc. The Using all of this information along with the network 

Event Manager 117 initializes status to dormant, sus- structure knowledge base, 854 determines whether the 

pended-record to nil. The purpose of each alarm attri- 5 alarm is redundant or correlated to other alarms, 

bute is more fully explained below in the section on the The Alarm Filter 118 of the preferred embodiment 

Inference Engine 122. determines whether alarms are redundant by both space 

FIG. 29 shows a portion of the Response Queue 116. and time correlation techniques. Other techniques of 
Response record 776 points to the Response Queue 116, filtering may be required for Expert Systems operating 
which is illustrated by records 778 and 780. The first 10 in other environments. By its knowledge of the network 
attribute in response record is record-id, a unique identi- topology obtained from the Network Structure Knowl- 
fier of the record. Second, response-type contains the edge Base 110, and access to events in the Event Man- 
type of test which requested the information in the ager 117 as well as the Bulletin Board 120, the Alarm 
response. Third, object-id contains the name of the Filter 118 examines newly received alarms comparing 
network object which the response concerns. Finally, 15 them to goals on the Bulletin Board 120 and events in 
value contains the value returned by the test (yes or no). the Event Manager 117 to determine whether they 
The unit-config attribute contains information regard- should be considered redundant, 
ing the configuration of the physical device as, for ex- Redundant alarms can be present by virtue of two 
ample, determined by the device's internal strapping. devices reporting the same problem such as the case 

Since each data communication network is different 20 where modem 78 of FIG. 1 and modem 84 both report 

and there are different needs for diagnostics for each a problem associated with transmission line 80. By 

network, a domain expert must almost surely provide knowing the network topology, the Alarm Filter 118 

custom expert information for diagnosing each net- can readily determine that both alarms relate to the 

work. For example, priority numbers often depend same problem. For example, if a high error rate alarm is 

more upon what the business environment needs from 25 reported by central modem 46 in the point to point 

the network than on the actual devices themselves. connection shown in FIG. 1, there is a strong likelihood 

FIG. 30 shows a portion of the Configuration Queue that a similar error reported by remote modem 50 at 

113. Configuration record 782 points to the Configura- about the same time is redundant In a similar manner, 

tion Queue 113, which is illustrated by records 784 and some types of alarms are repeatedly transmitted until 

786. The first attribute in a configuration record is re- 30 told by the network manager to quit, thus multiple 

cord-id, an unique identifier of the record. Second, alarms can be produced in that instance. It is also possi- 

object-id contains the name of the object for which the ble, with some network topologies such as mesh-like 

configuration has been changed. Finally, various other configuration, that a single alarm produced by a single 

attributes will contain information on how the configu- device could take two or more different paths to the 

ration has changed. Those skilled in the art will under- 35 network manager. Such alarms, in the preferred system, 

stand how to arrange such information, which informa- would have the same time stamp and could thus be 

tion is highly dependent upon the particular system and eliminated by the Alarm Filter 118. 

devices available, but is not important to this discussion. Due to finite queue sizes, it may be necessary or desir- 

FIG. 31 shows how the Event Manager 117 queues able to give the power to delete lower priority alarms to 
requests for information from the Network Manager 24. 40 the Alarm Filter 118 also. For example, if a major fail- 
First, after the start block 799, block 800 determines ure occurs which in effect overpowers the ENDS 10 
whether the Request Queue 115 is empty. If so, 802 with alarms, the Alarm Filter 118 can discard alarms 
transfers control to block 704 of the Controller 112. (preferably but not necessarily in accordance with their 
Otherwise, 804 retrieves the next information request priority) in order to prevent a queue overflow or system 
record from the Request Queue 115 (constructed by the 45 crash. 

Network Test Manager). Block 806 then encodes this If an alarm is found to be redundant, 856 deletes the 

information into a request event interpretable by the alarm record and control is returned to 842. Otherwise, 

Network Manager 24. Finally, 808 sends the request 858 adds the alarm record to the Goal Queue within 

event to the Network Manager 24. Control then returns Bulletin Board 120 and control returns to 842. 

to 800 where the process begins to repeat. 50 The flow-chart of FIG. 33 does not address what 

FIG. 32 shows an example of a Request Queue 115. happens if an alarm is correlated with other alarms 

Request record 810 points to the Request Queue 115 which have been received. This is because the course of 

containing records 812 and 814. The first attribute in the action to be followed in this instance can be highly 

record is object-id, which contains the name of the domain dependent. In some cases, receipt of a corre- 

object for which information is desired. The other attri- 55 lated alarm can exactly or nearly exactly identify a 

bute is request, which contains the name of the test or problem making diagnostics trivial. In other cases it 

instruction requested. may complicate the diagnostic process. In some in- 

A1 ... stances, receipt of an alarm correlated to a currently 

Alarm Miter active goal may mean that processing of the goal can be 

FIG. 33 is a flow-chart of the operation of the Alarm 60 terminated. In other instances, the receipt of a corre- 
Fdter 118. After the start block 840, block 842 deter- lated goal may simply mean that more information if 
mines whether the Alarm Queue 114 is empty. If so, 844 available to apply to solving the problem at band. Ac- 
transfers control to Controller block 704. Otherwise, cordingly, the handling of correlated alarms is best left 
846 retrieves the next alarm record from the Alarm to the individual design of the system. 
Queue 114. Block 848 then determines the time the 65 . ■ 
alarm was received by the time-received attribute of the Inference Engine 
alarm record. Next, 850 determines the type of the The Inference Engine 122 operates using the knowl- 
alarm associated with the alarm record from the alarm- edge of the Domain Expert 101 contained in the Expert 
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Information Structure 111. This Expert Information tion Structure 111 with higher probability, least inter- 
Structure 111 is a knowledge base which is divided into ruptive or fastest tests on the left to enhance operation, 
many knowledge sources, one for each type of alarm to Other schemes for prioritizing the process of traversing 
be handled by the Inference Engine 122. By dividing the tree are possible. In this example, the left-most possi- 
the knowledge in this manner, knowledge which is not 5 ble cause of this problem is a transient 602 so that goal 
currently needed is not loaded into memory, thus con- (shown as 602*) is instantiated below the general goal 
serving memory. To speed operation a cache may be 600' in memory as shown in 822. 
desirable so that the most recently used knowledge For the next step, there is only one possibility, that 
sources (e.g, the five most recently used) may be held in being the test 608 which is instantiated below 602 as 
the cache using conventional disk caching techniques. 10 608' as shown in 824. Once added to the memory model, 
During the Expert Knowledge Acquisition process, the the Inference Engine 122 instructs the Network Test 
Domain Expert 101 can concentrate on the knowledge Manager 124 to conduct the associated test (if required) 
required to solve one problem at a time making the or otherwise obtains the answer (e.g. from the user in 
entry of knowledge somewhat modular and leading to manual mode) to 608'. In this case, assume the answer is 
fewer errors. Knowledge can be added incrementally as 15 "yes" in which case the process proceeds to step 609 
required by the Domain Expert 101 or Operator 128. (Central DCD on?) in FIG. 25 A- Thus, 609' is added to 

In operation, when the alarms are posted to the Bulle- the memory model by instantiating 609 as shown in 826 
tin Board 120, the Controller 112 marks one as active after which the test indicated in 609' is performed. As- 
for use by the Inference Engine 122. The Inference suming that the result of 609* is "yes", the transient 
Engine 122 then maps this active goal to its appropriate 20 nature of the problem is confirmed and 612' (Confirm 
knowledge source using, for example, a look-up table. If Transient, a copy of 609) is instantiated to memory as 
the knowledge source is not currently in memory or shown in 828, and the goal has been solved. At this 
cache, it is loaded from disk. Then, the Inference En- point, the Controller 112 selects the next goal for pro- 
gine begins to solve the goal by a process called **instan- cessing after logging the results of this instantiation 
tiation" herein. This is the process of building a dy- 25 process to the printer 20 or disk file if desired, 
namic trace on the Bulletin Board 120 of a goal tree As shown in this example, the instantiating process is 
corresponding to the goal's solution. The term "instanti- a step by step cloning process which produces a clone 
ation", as used herein, is similar in meaning to the use of of the applicable portions of the goal tree corresponding 
the term in connection with the Prolog language and to the goal being processed. During each stage of in- 
other artificial intelligence oriented languages. In Pro- 30 stantiation, the knowledge source is reproduced using 
log, a variable is instantiated when there is an object for the information from the alarm to refine the part of the 
which the variable stands for: for example, when a knowledge source which is placed in memory as the 
variable has been replaced by a constant. In the present Inference Engine 122 systematically works through the 
invention, a node is instantiated when variables associ- goal's solution using a recursive call to itself. This pro- 
ated with the node have been replaced by facts such as 35 cess will obviously produce a different tree for each 
alarm type, configuration information, priority, time, solution to the goal, but retains the knowledge source as 
user supplied information, network database informa- the generic for each type of goal, 
tion, test results, etc. as the expert knowledge structure During the instantiation process, the Inference En- 
is traversed. gine 122 may require the resources of the Network 

This instantiating process may be thought of as a step 40 Structure Knowledge Base 110 as well as those re- 
by step "cloning" of the knowledge source beneath the sources previously mentioned. It directly interfaces 
active goal. But, since each type of goal has its own with this Knowledge Base 110 in the preferred embodi- 
knowledge source associated with it, and since some ment and can query it to obtain, for example, connec- 
knowledge in the knowledge source may not be appli- tion information which may be needed to solve the goal, 
cable to the specific active goal, the resulting trace will 45 ( Of course, the instantiation process may proceed 
rarely look like an exact clone of the knowledge source. somewhat differently depending upon the mode of op- 
To clarify, refer back to FIG. 25A which corresponds eration of the system. In Automatic Mode, the Infer- 
to a knowledge source for a point-to-point central RLF ence Engine 122 may simply proceed unassisted with 
alarm. This instantiation process for a point-to-point obtaining the information needed to solve a goal. In 
central RLF alarm caused by a transient (approximately 50 some cases, as previously described, the goal may be 
the left-most path of FIG. 25A) is shown in FIG. 34. suspended to allow operation on other goals. In the 
For simplicity, the numbers in the nodes of FIG. 34 Manual Mode, requests for information or tests must be 
correspond to the legend numbers in FIG. 25A except printed to a screen or the system otherwise requests 
that the "prime** designation has been added to distin- approval or operator assistance. The Operator 128 is 
guish the clone from the knowledge source, 55 presented with three choices: pause, abort or answer 

FIG. 34 represents a conceptual view of a time se- query in the preferred embodiment. In the Semi- 
quence of the cloning of the knowledge source in mem- Automatic Mode, the Inference Engine 122 must either 
ory as the Inference Engine 122 operates on the goal. look up the test on a map or examine an attribute associ- 
Note that if desired, such a graphical representation of ated with the test or otherwise determine whether or 
the cloning process could be produced on a monitor in 60 not to proceed with the test or request Operator assist- 
real time to show the actual processing of the goal. At ance. 

step 820, goal 600' (point-to-point Central RLF) is in- Although the above example is somewhat simple, 
stantiated with the particular information inherited those skilled in the art will appreciate the instantiation 
from the goal. When it begins analysis of the problem, it process with more complex goals after considering this 
begins, by convention, with the left-most branch of the 65 example in conjunction with the following more de- 
goal tree of FIG. 25A and works downward and tailed description. The following pseudocode describes 
toward the right. With this convention in mind, the the operation of the Inference Engine with comments 
Domain Expert 101 may prepare the Expert Informa- surrounded by /'and*/: 
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INFERENCE-ENGINE (Node. Parent. Go*]) 
Determine node- type of Node; 
if node-type of Node = AND node or OR node or 
KS-Node or Oil-Node 
New-Node := Instantiate-Hypo-Node (Node. Parent, Coal); 
/* Instantiate the Flow-Chart Node on the Bulletin Board 
under the Parent node for the current coal */ 

else 

New-Node :■= Instahtiate-F1ow-Chart-Node(Node, Parent, Goal); 
/* Instantiate the Hypothesis Tree Node on the Bulletin Board 
under the Parent node for the current Goal V 



case node-type of Node 

Conclude-Node print conclusion attribute of New-Node; 
Return (NIL); 

/• back to controller, indicating the completion of a goal V 

Fact-Node: print fact attribute of New-Node; 

Neat-Node :« Get-Fact-Node-Next- 
Node(Node, New-Node, Goal); 

Inference-Engine (Next-Node, 
New-Node, Goal); 

Confirm-Node: Print pre-description attribute of New-Node; 

Next-Node :« Get-ConfirnvNode-Nexi- 
Node (Node, New-node, Goal); 
Inference-Engine (Next-Node, New- 
Node Goal); 

Count-Node: Next-Node := Get-Count-Node-Next 
Node(Node, New-Node, Goal); 
Inference-Engine (Next-Node, 
New-Node, Goal); 

Call-Node: Next-Node = Get-Call-NodeNext- 

Node^ode, New-Node. Goal); 
lnferencc-Enginc(Ncxt'Node» New-Node. 
Goal); 

Test-Node: Next-Node := Get-Test-Node-Next- 

Node(Node. New-Node. Goal); 

If Next-Node <> NIL 
Inference-Engine (Next-Node, 
New-Node, Goal); 
else 

Determine its-state of Goal; 

Case ks-state of Goal 

Abort; Return (NIL); 

Pause: Set Return-Node attribute of 

Goal to Node; 

Set Suspended-Node 
attribute of Goal to Parent; 

Suspend: Set Return-Node attribute of 

Goal to Next-Node; 

Set Suspended-Node attribute of 

Goal to New-Node; 

Exit to Controller; 

AND node: Next-Node := Get-And -Node-Next-Node 
(Node, New-Node, Goal); 
Inference Engine (Next-Node, New-Node, 
Goal); 

OR node: Next-Node := Get-Or-Node-Next-Node 

(Node, 
New-Node, Goal); 
If Next-Node <> NIL 
Inference-Engine (Next-Node, New-Node, 
Goal) 

else 

Determine ks-state of Goal; 
CASE ks-state or Goal 
abort; Return(NIL); 

pause: set Return-Node attribute of Goal 
to Node; 

set Suspended-Node attribute of 
Goal to Parent; 
Exit to Controller; 
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Suspend: set Return-Node Attribute of 
Goal to Next-Node; 
set Suspended-Node attribute of 
Goal to New-Node; 
Exit to Controller; 

KS-Node: Next node : « Get-Ks-Node-Next-Node(Node, New- 
Node, Goal); 

If Next-node < > NIL 
Inference-Engine (Next-N6de,New-Nodt,Goal); 

else 

return (NIL) • 



FIG. 35, which is broken down into FIGS. 35A-35D, pointer to the goal which the Inference Engine 122 is 

is a flow-chart version of the pseudocode listed above attempting to solve). After the Start block 880, step 881 

showing the operation of the Inference Engine 122. The determines the node type of Node. Next, 882 determines 

Inference Engine 122 is called with parameters "Node" whether the node type is Knowledge Source (KS), OR, 
for the knowledge node (a pointer to the node to deter- — AND or CALL. If so, 883 builds (instantiates) a hy- 

mine the truth of), Parent (a pointer to the node which pothesis tree node under the Parent Node on the Bulle- 

points to Node and which was the Node parameter in tin Board 120, using a routine such as the one described 

the previous call to Inference Engine) and Goal (a by the following pseudocode. 



INSTANTIATE-rfYPONODECNode, Parent, Goal) 
bypo-list := all instances of Node; 

/* Each knowledge nodt in Knowledge Source has an INSTANCES 
attribute which contains a list of all instances of it.*/ 

/* If there are no instances of node, instantiate new node */ 

If (hypo-list «= nil) 
New-Node := Baild-Hypo-NodeCNode, Parent, Goal); 
Retum(New-Node); 

else /* there are instances of node V 

Instance := find from the Node-Stack attribute of Goal the entry 
that is an instance of Node; 

/* Node-Suck attribute of Goal contains a node list which 
corresponds to all the node instill re* thai have already been 
instantiated under the Goal node on the Bulletin Board V 

/• if no instance of Node corresponds to Goal, Instantiate new 
node •/ 

UCInstance *» nil) 
New-Node :«> Build-Hypo-Node(Node, Parent, Goal); 
Return(New-Node); 



/* an instance of Node has already been Instantiated for Goal V 

tftforget attribute of Instance b "yes") 
/• Instantiate another instance of Node */ 
New-Node Build-Hypo-Node(Node,Parcnt,Goal); 
Return(New-Node); 



else 



/* forget is "no", do not need to instantiate another 
instance of node V 

Return(Instancc); 



The INSTANTTATE-HYPO-NODE routine calls Build-Hypo-Node, 
which is described by the following psuedo code: 



BUILD-HYPO-NODE (Node. Parent, Goal) 
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New-Node := nuke an instance of Node; 
Set Instance-of attribute of New-Node to Node; 
Set reverse-node attribute of New-Node to Parent; 
/* add this New-Node to the value list of the node-stack 
attribute of Coal */ 

add New-Node to node-stack attribute of Coal; 

determine node-type of Parent; 

cae node-type of Parent: 
AND, OR, KS-NODE: 

/" determine the next due-to-condition node-value pair 
associated with the Parent and update due-to-lraces 
attribute of parent */ 

Node-Value-Pair: = get next node-value pair from due- 
fo-condition attribute of Parent; 
delete the Node- Value-Pair from diie-to-conditions 
attribute of parent; 

New-Node- Value-Pair: a replace the node field of the 
New-Value-Pair with New-Node; 
Add the New-Node- Value-Pair to due-to-trace attribute 
of Parent; 

CALL NODE: 



/* determine the next function-condition function- 
value pair associated with the Parent node, and 
update due-to-traces attributed of Parent V 

Node- Value-Pair: ~ get next function-value pair from 
(unction-condition attribute of Parent; 
delete Node- Value-Pair from function-condition 
attribute of Parent; 

New-Node-Value-Pair: *= replace the node field of the 
Node-Value-Pair with New-Node; 
Add the New-Node- Value-Pair to Due-to-trace attribute 
of Parent; 

Return (New-Node); 



If 882 determined that the knowledge node was not 
of type Knowledge Source, OR, AND or CALL, 884 
routine Instantiate-Flow-Chart-Node to Instantiate a 



flow-chart node for the Node under the Parent node on 
the Bulletin Board 120. A pseudocode routine for per- 
forming this function is shown below: 



INSTANT1ATE-FLOW-CHART-NODE (NodcParen^Goal) 
flow-list := all instances of Node; 

/* each knowledge node in knowledge source has an Instance 
attribute which contains a list of all instances of it */ 

inflow-list = nil) 

/* if there are no instances of node, build new node */ 

New-Node BuJd-Flow-Chart-Node{Node, Parent, Goal); 
else 

Instance :« find from the Node-Stack attribute of Goal the entry 
which is an instance of Node; 



/* Node-Stack attribute of Goal contains a node list which corresponds to 
all the node instances that have already been instantiated under the Goal 
node on the Bulletin Board */ 

if(Instance - nil) 

/• If oo instance of Node corresponds to Goal, instantiate New Node from 
NodeV 

New-Node := Build-Flow-Chari-Node(Node, Parent, Goal); 
else /• Instance exists */ 

/* Instantiate a copy from Instance node */ 

New-Node := Build-Flow-Chart-Nod eOnstance^Paren^Goal); 
Return (New-Node); 
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-continued 



INSTANTIATE-FLOW-CHART-NODE calk the BUILD-FLOW- 
CHART-NODE routine which is described by the following Pseudocode. 



BUILD-FlX)W-CHART-NODE(Nodc 1 Parent, Go*!) 
. New-Node :<= mtke an instance of Node; 

Set iiutanceof attribute of New-Node Co Node; 

Set Reverie-node attribute of New-Node to Parent; 

Add New-Node to Node-Suck attribute of Goal; 

If (truth- value attribute of Parent • "yes") 
set yes-node attribute of Parent to New-Node; 

else 

set no-node attribute of Parent to New-Node; 
Return (New-Node); 



After instantiating the hypothesis tree node or flow- 
chart node, 885 determines whether Node is a CON- 20 
CLUDE node. If so, 886 prints the CONCLUSION 
attribute of the node. Block 887 then returns control to 
the routine which called the Inference Engine. Other- 
wise* 890 determines whether Node is a FACT node. 

If Node is a FACT node, 891 prints the FACT attri- 25 
bute of Node. Block 892 then determines the Next- 
Node of the FACT node by calling a routine GET- 
F ACT-NODE-NEXT-NODE which gets the next 
node of a Fact node. A pseudocode representation of 
this routine is as follows: 30 



GET-FACT-NODE-NEXT-NODE (Node, New-Node, Goal) 
set the truth-value attribute of New-Node to "yes"; 
Next-Node := get the value of yes-node attribute 
of New-Node; 
. Return (Ncxt'Node); 



35 



Block 893 then recursively calls the Inference Engine 
with pointers to Next-Node, New-Node and Goal as 
parameters Node, Parent, and Goal. Otherwise, 894 40 
determines whether Node is a CONFIRM node. If so, 

895 prints the CONCLUSION attribute of Node. Next, 

896 calls a routine, GET-CONFIRM-NODE-NEXT- 
NODE, which determines the next node of a CON- 
FIRM node (called Next-Node). 45 



Confirm-Pair: 



Confirm-Node: 



GET-CONFIRM -NODE-NEXT-NODE (Node, New-Node, 
Goal) 

*> get the node-value pair from the 
branch-to-and -confirm attribute of 30 
New-Node; 

« get the node 5cld of the 
Confirm-Pair, 
/* node field of Confinn-Pair contains the node 
identifier to be confirmed V 
Confirm-Value: - get the value field of the 55 
Confirm-Pair, 
/* value field of the Confinn-Pair contains the , 
value to be set or oonfirmed for the 
Confirm-Node */ 
Sel the truth-value attribute of Confirm-Node to 
Confirm- Value; 60 
Return (Confirm-Node); 



Block 897 then calls the Inference Engine with pa- 
rameters Next-Node, New-Node and Goal. Otherwise, 
898 determines whether Node is a COUNT node. 65 

If block 898 determines that the node is a COUNT 
node, block 899 calls a routine, GET-COUNT-NODE- 
NEXT-NODE, to determine the next node of a 



COUNT node (called Next-Node). A pseudocode rep- 
resentation of this routine is as follows: 



GET-COUNT-NODE-NEXT-NODE (Node, New-Node, Goal) 
IF (the value of count-value attribute of New Node < the 
value of count attribute of New-Node); 
/♦ count-value attribute of a COUNT node is 
always initialized to 0. This count-value is 
incremented by 1 every time this node is traversed, 
so long as this value remains leas than that of count 
attribute which the expert had assigned V 
print conclusion-if-true attribute of New-Node; 
set truth-value attribute of New Node to ''yes"; 
increment the value of count-value attribute of 
New-Node by 1; 

Next-Node := get the value of yes-node attribute 

of New-Node; 
Return (Next-Node); 

else 

/* The value of count-value attribute is equal to 
the value of count attribute which the expert had 
assigned. Now, it is time to break the loop; no need 
to increment the value of count-value attribute of 
New-Node. V 

print condusioh-if-false attribute of New-Node; 

set truth-value attribute of New-Node to "no"; 

Next-Node ;« get the value of no-node attribute 
of New-Node; 

Return (Next-Node); 



Block 900 then calls Inference Engine with parame- 
ters Next-node, New-Node and Goal. Otherwise, 898 
sends control to 910, which determines whether Node is 
a TEST node. If so, 912 calls a routine, GET-TEST- 
NODE-NEXT-NODE, to determine the next node of a 
TEST node (called Next-node). A pseudocode routine 
performing this function is shown below; 



GET-TEST-NODE-NEXT-NODE (Node, New-Node, Coal) 
If (truth value attribute of New-Node « nil) 

print pre-description attribute of New-Node; 
Neat-Node :=* call Net-Test-Manager (New- 
node, Goal); 
Return (Next-Node); 
else if (forget ■= false /* do not forget */ 

if (truth-value attribute of New-Node » "yes") 
Next-Node :« get the value of yes-node 
attribute of New-Node; 

else 

Next-Node := get the value of no-node attribute 
of New-Node; 
Return (Next-Node); 
else /• forget «= troth •/ 

print pre-description attribute of New-Node; 
Next-Node: = call Net-Test-Manager (New-Node, 
Goal); 
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Return (Next-Node); 



Block 914 then determines whether Next-Node is nil. 
If not, 916 calls the Inference Engine with parameters 
Next-node, New-Node and Goal. Otherwise, 917 deter- 
mines the value of the KS-state attribute of Goal. The 
value can be Abort, Pause or Suspend. Block 918 then 
determines whether the KS-state is "Abort". This 
would in response to a query, the Operator instructed 
the Inference Engine not to continue processing the 
goal. If so, 920 returns control to the Controller 112. 

If KS-state is not "abort" on the other hand, 922 
determines whether the KS-state attribute of Goal is 
"Pause". This would indicate that in response to a query 
the Operator instructed the Inference Engine 122 to 
wait until the Operator informed it that he had the 
requested information, and then to resume processing of 
the goal by invoking the "Resume" command. If so, 924 
sets the Return-node attribute of Goal to Node. Next, 
926 sets the Suspend-node attribute of Goal to Parent. 
The latter two blocks enable the Controller to resume 
processing of Goal by calling Inference Engine 122 
with parameters Return-node of Goal, Suspend-node of 
Goal and Goal. Block 928 then returns control of the 
Controller 112. 

If block 922 found that the KS-state of Goal is not 
"Pause" on the other hand, it must be "Suspend". In 
that case, 930 sets the Return-node attribute of Goal to 
Next-node. Next, 932 sets the Suspend-node attribute of 
Goal to New-Node. The latter two blocks enable the 
Controller to resume processing of Goal by calling 
Inference Engine with parameters Return-node of 
Goal, Suspend-node of Goal and Goal. Block 934 then 
returns control to the Controller 112. 

If 910 found that Node was not a TEST node, on the 
other hand, 936 determines whether the node is a 
CALL node. If so, 938 calls a routine, GET-CALL- 
NODE-NEXT-NODE, to determine the next node of a 
CALL node (called Next-node). A pseudocode routine 
to perform this function is shown below: 



OET-C ALL-NODE-NEXT-NODE (Node, New-Node, Goal) 

Function-Node := get the node field of the first function- 
value pair of the function-condition attribute of New-Node; 

/* Function-Node is the next-to-be-called 
function node of the New-Node •/ 
Trace := get the first node-value pair in the Due-To-Trace 
attribute of New-Node; 

Trace-Node := get the node field of Trace; 

/• Trace-Node is the currently traced or 
instantiated called node */ 
Trace- Value :«= get the value field of Trace; 

/• Trace-Value is the needed return value of 
Trace-Node •/ 
if (truth-value attribute of New-Node « nil) /• if truth 
value not initialized */ 

if (Trace — nil) 

/* There are no entries on Due-To-Trace attribute 
of New-Node. 

This is the first time this node is traversed */ 
print pre-description attribute of New-Node; 
Next-Node :« Find-Hypo-Node (New-Node, Function- 
Node, Coal); 

*/ The Find-Hypo-Node routine is used to check 
whether the called node, Function-Node, has 
already been instantiated. If it is already 
instantiated, the old node is returned; 
otherwise, the Function-Node is returned •/ 

Return (Next-Node); 
else /• Trace-Node has already been processed V 

Called-Value :» get the Truth-Value attribute of the 



Trace-Node; 

if (CaUed-Value = Trace-Value) 

/* The truth-value returned by the Called Node, 
5 Trace-Node, is the tame as the Trace-Value */ 

set Truth- Value attribute of New-Node to "yes"; 
print message in Coscluiton-if-true attribute of 
New-Node; 

Next-Node := yes-node attribute of New-Node; 
Return (Next-Node); 

10 else 

/■ The truth-value returned by the called node, 
Trace-Node, is not equal to the Truth- Value. V 
set Truth-Value attribute of New-Node to M no w ; 
print message in Conclusioo-if-false attribute of 

New-Node; 

15 Next-Node :- no-node attribute of New-Node; 

Return (Next-Node); 
else /* truth-value of New-Node already exists */ 
if (forget = nil) /• do not forget •/ 
if (truth-value of New-Node - "yes") 

Next-Node :« yes-node attribute of New-Node; 
» Return (Next-Node); 

else /* truth-value of New-Node - "no" •/ 

Next-Node := No-Node attribute of New-Node; 
Return (Next-Node); 
else /• yes! forget the current truth value of New-Node V 
print pre-description of New-Node; 
Next-Node := Find-Hypo-Node (New-Node, 
23 Function-Node, Ooal); 

Return (Next-Node); 

GET-CALL-NODE-Next-Node calls Find-Hypo-Node 
routine to find the hypothesis tree node. 

30 FIND-HYPO-NODE (New-Node. Hypo-Node, Goal) 

/• This routine is called to check whether the 
Hypo-Node has already been instantiated. If so, it 
finds the node name, updates the appropriate 
parameters, and returns the node. Otherwise, 
it just returns the Hypo-Node to be 
35 instantiated. V 

hypo-list := get all instances of Hypo-Node; 
/• Each Knowledge node has an Instances attribute 
which contains a list of all instances of it. V 
if (hypo-list = nil) 
/* if there are no instances of Hypo-Node */ 
40 Return (Hypo-Node); 

else 

/* forget is turned on " 

if (forget attribute of Hypo-Node e= "yes"); 

Return (Hypo-Node); 
else 

43 . Instance := find from the node-stack attribute 

of Goal the entry which is an instance of Hypo-Node; 
if (Instance = nil) 
Return (Hypo-Node); 
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CALL : 



add New-Node to reverse-Node attribute of 
Instance; 

case Node-Type of New-Node: 
AND, OR or KS: 
/• determine the next due-to-condition node- 
value pair associated with New-Node and update 
duo-to-Traces attribute of New-Node */ 
Node-Value-Pair := get next node-value pair in 
due-to-condition attribute of New-Node; 
/• Remove the node-value pair from due-to- 
condition attribute of New-Node, and update 
due-to-traces attribute of New-Node */; 
delete the Node- Value-Pair from due-to- 
conditions attribute of New-Node; 
New-Node-Value-Pair := replace the Node field 
of the Node-VaJue-Pair with Instance node; 
Add the New-Node- Value-Pair to Due-To-Trace 
attribute of New-Node; 
Next-Node := get instanceof attribute of 
Instance node; 
Return (Next-Node); 

/* determine the next function-condition pair 
associated with New-Node. Remove the pair 
from the function-conditions attribute of New- 
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Node and update the due-to-trace* attribute of 
New-Node with the new pair •/ 
Node-Value-Pair := get next Node- Value-Pair in 
function-conditions attribute of New-Node; 
Delete Node-Vahie-Pair from functkm- 
conditions attribute of New-Node; 
New-Node- Value-Pair :- replace the Node field 
of the Node-Value-Pair with Instance node; 
Add the New-Node- Value-Pair to the due-to- 
traces attribute of New-Node; 
New-Node :« get inttancevof attribute of 
Instance node; 
Return (Next-Node); , 

Block 940 then calls the Inference Engine 122 with 
parameters Next-Node, New-Node and Goal. Other- 
wise, 9A2 determines whether Node is an AND node. If 
so, 944 calls a routine, GET-AND-NODE-NEXT- 
NODE, to get the next node of an AND node (called 
Next-Node). A pseudocode implementation of this rou- 
tine is as follows: 



G ET- A ND-N ODE- NEXT-NODE (Node, New-Node, Goal) 

Condition-Node get the Node field of the first node-value 

pair in the due-to-condition attribute of New-Node; 

/• Condition-Node is the next to-be-traced child 
node of the New-Node */ 

Trace :« get the first node-value pair in the Due-To-Trace 

attribute of New-Node; 

Trace-Node get the Node field of Trace; 

/* Trace-Node is the currently instantiated or 
traced child node of the New-Node V 

Trace-Value :« get the value field of Trace; 

/* Trace-Value is the needed return value of the 
current instantiated or traced child node V 

If (truth-value attribute of New-Node <> nil) 

/* If the truth-value of new-node already exists, 
there is no need to trace the children nodes. 
Return back to the reverse node V 
Reverse-Node := get the reverse-node attribute of 
New-Node; 

Next-Node := get the insunce-of attribute of Reverse- 
Node; 

Return (Next-Node); 
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New-Node should be true. Set the truth-value to 
"yes** and return back to the Reverse Node V 
truth-value attribute of New-Node "yes"; 
print coocluaon-if-true attribute of New-Node; 
Reverse-Node : = get the reverse-Node 
attribute of New-Node; 
Next-Node get the iaitance-of attribute 
of Reverse-Node; 

Return (Next-Node); n 

else 

/* we have not yet exhausted all the Children 
nodes. Let's continue to trace the next Child, 
Condition-Node. */ 
Next-Node := Find-Hypo-Node 
(New-Node, Condition-Node, Goal); 
Return (Next-Node); 



else 



/• truth-value attribute of New-Node is nil */ 
If ((Condition-Node <> nil) and (Trace = nil)) 
/* Trace is nil indicates that this is the first time 

the new-node is traversed, and no child nodes 

yet traced •/ 
print pre-description attribute of New-Node; 
Next-Node := Find-Hypo-Node (New-Node, 
Condition-Node, Goal); 

/* Find-Hypo-Node routine is called to check if 
the Condition-Node has already been 



Block 946 then calls the Inference Engine 122 with 
parameters Next-Node, New-Node and Goal. Other- 
wise, 948 determines whether Node is a Knowledge 
20 Source node. If so, 950 calls a routine, GET-KS- 
NODE-NEXT-NODE, to get the next node of a 
Knowledge Source node (called Next-Node). A 
pseudocode routine to perform this function is as fol- 
lows: 

25 

GET-KS-NODE-NEXT-NODE (Node, New-Node, Goal) 
Condition-Node := get the node field of the first node- 
value pair in the due-to-condition attribute of New-Node; 
/* Condition-Node is the next to-be-traced child 
30 node of the New-Node V 

Trace \~ get the first node-value pair in the Due-To-Trace 

attribute of New-Node; 

Trace-Node :*= get the Node field of Trace; 

/* Trace-Node is the currently instantiated or 
traced child node of the New-Node V 
35 Trace-Value :« get the value field of Trace; 

/* Trace- Value is the needed value of the 
currently instantiated or traced child node, 
Trace-Node */ 
if ((Condition-Node <> nil) and (Trace » nil)) 
/* first time this New-Node i* traversed; no children yet traced "/ 
40 print pre-description attribute of New-Node; 

Next-Node := Find-Hypo-Node (New-Node. 
Condition-Node, Goal); 
Return (Next-Node); 
else if (Trace <> nil) /• at least one child has been 
traced V 



Return (Next-Node); 

else 

If (Trace <> nil) 
/• at least one condition has been 



Traced •/ 

if (truth-value attribute of Trace-Node <> 

Trace-Value) 
/* The truth-value of this New-Node is false, if 
one of its children is false, which is indicated by 
the truth-value attribute of Trace-Node. There is 
no need to trace the next child. Set the truth-value 
to *W\ and return back to the reverse-node */ 

truth-value attribute of New-Node **no w ; 

prinl conclusion-tf-false attribute of New-Node; 

Reverse-Node :» get the Reverse-Node attribute 

of New-Node; 

Next-Node :— get the instance-of attribute of 
Reverse-Node; 
Return (Next-Node); 
else if (Condition-Node = nil) 
/* condition-node = nO indicates thai aQ the 
children nodes have been traced, and there 
has not been one that is false; therefore, this 



if (truth-value attribute of Trace-Node = Truth- 
Value) 

/• Current child traced returned true. Knowledge 
Source node roust be true. There is no need to 
trace or instantiate the next child. Infercndng on 
this goal now complete. */ 
print concluslon-if-true attribute of New-Node; 
truth- value attribute of New-Node ;» **yes*'; 
return (nil); /• Controller will then delete the 
entire trace associated with the goal V 
else /* truth-value attribute of Trace-Node < > 
Truth-Value V 
/* if last one processed returned false, goal b 
false •/ 
if (Condition-Node « nil) 
/* Condidon-Node ~ nil indicates that there are 
no children left to be traced and there has not 
been one child found to be true. Therefore, 
New-Node must be false. V 
print oooclusion-if-false attribute of New-Node; 
truth-value attribute of New-Node **no"; 
Return (nil) 

/• Controller win later delete the entire trace 
associated with the Goal */ 

/♦ Otherwise, process next child pointed to by 
65 Knowledge Source node •/ 

else 

/* We have not yet exhausted all the children 
nodes! Continue to find the next child to be 
trace or instantiated */ 
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Next-Node := Find-Hypo-Node (New-Node, 
Condition-Node. Goal) 
Return (NexVNodc) 



Next, 952 determines whether Next-Node is nil. If 
not, 954 calls the Inference Engine 122 with parameters 
Next-Node, New-Node and Goal. If Next-Node is nil, 
956 returns control to the routine that called the Infer- 
ence Engine 122. If 948 found that Node is not a Knowl- 
edge Source node, it must be an OR node. In this case, 
958 calk a routine, GET -OR-NODE-NEXT-NODE, 
to get the next node of an OR node (called Next-Node). 
A pseudocode routine for this operation is shown be- 
low: 
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GET-OR-NODE-NEXT-NODE (Node, New-Node, Goal) 

Condition-Node := get the node field of the first node-value pair 
in the due-to-condition attribute of New-Nodc; 

/* Condition-Node is the next to-be-traced child 
node of the New-Node */ 
Trace := get the first node-value pair in the Due-To-Trace 
attribute of New-Nodc; 
Trace-Node := get the node Held of Trace; 

/• Trace-Node is the currently traced child 
node of the New-Node V 
Trace- Value :«= get the value field of Trace; 

/■ Trace- Value is the needed value for the 
currently traced child node, Trace-Node. V 
if (truth-value attribute of New-Node <> nil) 

/* The truth-value of New-Node already exists, 
return back to reverse node •/ 
Reverse-Node := get the reverse-Node attribute of 
New-Node; 

Next-Node := get the instance-of attribute of 
Reverse-Node; 
Return (Next-Node); 
else if ((Condition-Node = nil) and (Trace = nil) and (Yes- 
Node attribute of New-Nodc = nil)) 

/* This node must be a terminal node that needs 
either a user response or a network test 
result •/ 

print pre-description attribute of New-Nodc; 
Next-Node := call Net-Test-Managcr (New-Node, 
Goal); ' 
Return (Next-Node); 
else if ((Condition-Node = nil) and (Trace = nil) and (yes- 
Node attribute of New-Node <> nil)) 

/* This node is a leaf node which points to a 
flow-chart knowledge with the first node 
contained in the yes-node attribute of the 
New-Node V 
print pre-description attribute of New-Node; 
Next-Node :«* get the next-node attribute of 
New-Node; 
Return (Next-Node); 
else if ((Condition-Node <> nil) and (Trace » nil)) 

/• no child nodes yet traced, this is the fust tune V 
print pre-description attribute of New-Node; 
Next-Node :«= Find-Hypo-Node (New-Node, Condition- 
Node, Goal); 

/* Continue to find the next child to be traced V 
Return (Next-Node) 
else if (Trace <> nil) /• at least one child has been 
traced */ 

if (truth-value attribute of Trace-Node — Truth-Value 
/• Current child traced returned true. This New-Nodc 
must be true. There is no need to trace the next child of 
New-Node, and it can be returned to the Reverse 
Node V 

print conclusion-if-true attribute of New-Node; 
truth-value attribute of New-Node :<= "yes"; 
Reverse-Node get the reverse-node attribute of 
New-Node; 

Next-Node := get the instance-of attribute of 

reverse-Node; 

Return (Next-Node); 
else /• truth-value attribute of Trace-Node <> 
Truth-Value V 
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if (Condition-Node = nil) 

/* Condition-Node = nil indicates that there are no . 
children left to be traced and there has not been one 
child found to be true. Therefore, this new-node 
must be false, and it's time to return back to the 
Reverse-Node V 

print conchuioo-if-ftlw attribute of New-Node; 
truth-value attribute of New-Node := "no"; 
Reverse-Node :» get the reverse-Node attribute 

of New-Node; 
Next-Node :*» get the instance-of attribute of 

Reverse-Node; 
Return (Next-Node); 
/* Otherwise, trace next child node pointed to by 
New-Node •/ 
ebc 

Next-Node :» Find-Hypo-Node (New-Node, 
Condition-Node, Goal); 
/* continue to find the next child node to be traced */ 
Return (Next-Node); 



960 then transfers control to 914. 

Earlier, those skilled in the art will note, a Delay node 
was also discussed. This node's function is trivial imple- 
ment and is therefore not discussed further either in 
pseudocode or flow-chart. Those skilled in the art will 
understand how to implement such function. 

The operation of the Inference Engine 122 is more 
easily understood in the context of a more familiar do- 
main such as the Expert Auto Diagnostic System of 
FIG. 23. FIG. 36 shows an example of a Bulletin Board 
120 for an Expert Auto Diagnostic System. 

As explained, the Alarm Filter 118 posts goal nodes 
associated with non-redundant alarms to the Bulletin 
Board 120. The Inference Engine 122 attempts to deter- 
mine the problems which caused the alarms associated 
with these goal nodes and to remedy the problems. It 
allows the user or Domain Expert 101 to trace its rea- 
soning by instantiating goal trees for each alarm node 
on the Bulletin Board. Another advantage of the B diet- 
ing Board 120 is thai it provides for suspendible in- 
ferencing. 

In FIG. 36, there is one goal on the Bulletin Board 
120. Goal-1 1010 represents the Overheat alarm from 
FIG. 24. The attributes of the Goal nodes in the exam- 
ple are NODE-ID, STATUS, PRIORITY, Knowledge 
Source, OBJECT-ID, TIME-RECEIVED and 
STATE. Other attributes could also be used. NODE- 
ID is a unique name of the node. STATUS indicates 
whether the node is running ("active"), ready to run 
("Posted"), waiting for results from the Network Man- 
ager 24 ("Suspended") or Paused by the user until he 
can determine the information requested ("Paused"). 
The Knowledge Source Attribute (KS) contains the 
name of the knowledge source used upon receiving the 
alarm associated with the goal. OBJECT-ID contains 
the name of the object which sent the alarm. TIME- 
RECEIVED contains the time the alarm was received 
by the Network Manager 24. STATE contains either 
"Suspended", to indicate that inferencing of the goal 
was suspended, or "new", to indicate that the Inference 
Engine 122 has not yet begun to process the goal. 

Upon being invoked with Overheats, Goal-1 and 
Goal-1 as the Node, Parent of the Node and Goal pa- 
rameters, the Inference Engine processes Goal-1 as 
follows. First, it uses the Expert Information Structure 
of FIG. 24 to instantiate an instance of the Overheats 
node 546 called Overheats-1 1014. Overheats-1 1014 has 
the following attributes: IS-A, INSTANCE-OF, DUE- 
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TO-CONDITIONS, Due-To-Trace, TRUTH- sage to the user, sets the truth-value attribute of Node 

VALUE and PARENT. IS-A contains the node type and returns the node which should be processed next, 

fin this case "KS-NODE"). INSTANCE-OP contains After Start block 1128, 1132 determines whether the 

the name of the node of which this is an instance (in this node type of Node is TEST node. If so, 1134 determines 

case "Overheats"). DUE-TO-CONDITIONS initially 3 whether Test-result is "yes". If so, 1136 prints conclu- 

contains the same values as DUE-TO-CONDITIONS sion-if-truc attribute of New-Node. 1138 sets truth- 

in the node of which this is an instance, in this case value attribute of New-Node to "yes". 1140 returns 

"(Radiator-leaks yes) (Coolant-low yes) (Bad-thenno- yes-Node attribute of New-Node, 

stat yes)". Node names are deleted as the nodes are if 1134 was n0> Node must be an OR node (only 

processed. DUE-TO-CONDITIONS is used to deter- 10 TEST nodes and OR nodes can request information), 

mine 1 the next child node to process. u42 prf^ conclusion-if-false, attribute of Node. 1144 

DUE-TO-TRACE initially contains nil. It is used to Kts truth-value attribute of New-Node to "no". 1146 

^ l ^°f* hlch of n^es names in DUE-JO- rcturns No-Node attribute of New-Node. 

CONDITIONS is currency being processed. TRUTH- v U32 was I148 determines whether Test- 

VALUE contains the truth value of the node. It initially 15 . resuh k lf ^ 1150 printe condusion.if.ttue 

ZSTi ^V"'^ or > on « Ae attribute of New-Node. 1152 sets truth-value attribute 

tenth value is determined. PARENT contains a pointer of New . Node t0 .. yes ». 154 ^ ^ node on the 

to the node which points to this ndc. In Aecase of the Expert Information Structure of which Node is an in- 
alarm node, such as Overheats 546. PARENT contains gtan ~ ^ ^ of ^ node h m Inverse 

a pointer to the goal node , Oojd-l. 20 Node attribute of New-Node. 

tJ?« Aen must determine the , f u48 WM , 15(J ^ COBdoiloB 4 HUie attri . 
tenth of Overheate usuig the Structured Flow Graph or fc f New-Node. 1158 sets truth-value attribute of 

cScu^„°S no ™ e P y m New - No ^ e te "St? ii6o™ s i^Sy t£ 

2J Expert Information Structure of which Node is an in- 
Network Test Manager stance. The name of that node is contained in Inverse 

FIG. 37 is a flow-chart of the operation of the Net- Node attributc of New-Node. 
work Test Manager 134 when the Inference Engine 122 Network Configuration Module 

calls it to request information from the user (in manual A . _ " . . , • , mM 

mode) or the Network Manager 24 (in automatic 30 The Network Coiifiguration Module 108 serves two 
mode). The Inference Engine 122 calls it with the pa- PW«. First, before ENDS 10 can be operated, the 
rameters New-Node (the node with the QUERY or Network Configuration Module 108 uses information m 
HAS-TEST attribute that is to be answered) and Goal Network Manager 24 Database Manager 30 to ini- 

(the goal with which Node is associated). After start Uali2e thc Network Structural Knowledge Base 110. 
node 1100, 1102 determines whether the ENDS 10 is 35 ^ Network Structural Knowledge Base 110 contains 
operating in manual mode. If not, 1104 determines the information about the interconnection of the network 
command to send to the Network Manager 24 which components which is needed in order to perform diag- 
will produce the information requested. It could do so nostics. 

by, for example, mapping the value of Node.Has-test Second, the Controller 112 invokes the Network 
(Lc. the Has-test attribute, of node) to the appropriate 40 Configuration Module 108 while ENDS 10 is operating 
network command by use of a table set up for such t0 update the Network Structural Knowledge Base 110 
purpose. Block 1105 then constructs a Request Node if network configuration has been changed since the 
such as node 812 in FIG. 32, setting "request'* to the last tune the Network Configuration Module 108 ran. 
network command and object to the Object-id attribute FlG 3 * " a flow-chart showing how this is done in 
of Goal. Block 1106 adds the request node to the Re- 45 the preferred embodiment After the Start block 1250, 
quest Queue 115. Block 1108 sets KS-state attribute of Wock determines whether the Configuration 

Goal to 'suspended' to inform the Controller 112 not to Queue 113 is empty. If so, 1254 transfers control to 712 
invoke the Inference Engine 122 on this Goal because of the Controller 112. Otherwise, 1256 retrieves the 
the Goal is waiting for information. next configuration node from the Configuration Queue 

If on the other hand 1102 determined that the test 50 U3 constructed by the Event Manager 117. Finally, 
mode was manual, 1112 prints query attribute. 1114 1258 then uses the information in the node to update the 
retrieves the response typed by the user. The allowed Network Structure Knowledge Base 110. Control then 
responses are "yes", "no", "abort" and "wait". If the returns to 1252. 

user typed "yes", 1118 returns control to the Inference - . . T 4 - , _ . . 

Engi»Yl22 with a value of yes. If the user typed "no", 35 Expert/Operator Interface to Terminal 

1120 returns control to the Inference Engine with a An example screen display 1300 from the Operator 
value of no. If the user typed abort, 1122 sets KS-state Interface Terminal 18 is shown in FIG. 40. In the pre- 
attribute of Goal to "Abort". 1124 then returns control fared embodiment, several windows are used to pres- 
to the Inference Engine 122 with a value of nil. If the ent the various functions as shown. In FIG. 40, the 
user typed "wait", 1125 sets KS-state attribute of Goal 60 display 1300 is illustrated in the Knowledge Acquisition 
to "wait". 1126 then returns to nil. process. A menu 1302 is presented as a pair of vertically 

FIG. 38 is a flow-chart of the operation of the Net- stacked menu selections at the right side of the display 
work Test Manager 124 routine which the Controller 1300. Of course, other menu arrangements are possible. 
112 calls to retrieve responses from the Response Queue Each menu selection corresponds with one of the menu 
116. Thc Controller 112 calls thc routine with parame- 65 selections presented in conjunction with FIG. 5. The 
ters Node (the suspended-node attribute of the goal remainder of the screen can be used to display the van- 
waiting for this information) and test-result ("yes" or ous features and functions of the Expert System 10 in 
"no") at 1128. The routine prints an appropriate mes- the individual windows. 



11/14/2003, EAST Version: 1.4.1 



r 



5,295,: 

59 

In the example shown, the Domain Expert 101 has 
loaded an existing Knowledge Source as shown in win- 
dow 1304 by moving a pointer to the desired Knowl- 
edge Source in a conventional manner. The Show 
Knowledge Source procedure has been activated and is 3 
shown in window 1508 with its associated lists of de- 
fined and undefined knowledge nodes. The Display 
Knowledge Source procedure has also been activated 
as shown in window 1310 in which a horizontally ori- 
ented graphic representation of the Knowledge Source 10 
is displayed. As seen, the graphic representation is too 
large to fully see within the window. Panning tech- 
niques as well as changing of window size and zooming 
techniques may be used to get other views of the 
graphic representation. In window 1312, a template is 15 
shown as for use in the Add Node and Modify Node 
procedures. A cursor such as cursor 1316 may be used 
to point to a desired operation, menu selection or item 
to add or modify in the template. A conventional key* 
board is used to type attributes into the template. 20 

In FIG. 41, a similar example screen display is shown 
for the system in the System Operations mode as see by 
the Operator. In the example shown, diagnostics opera- 
tions are shown in a Diagnostics Operations Window ^ 
1320 in which the session (similar to the sample session 
of Table 1) takes place. The Bulletin Board Status is 
shown in windows 1322. Help and explanation from the 
menu help selection is shown in window 1326 and the 
status of events and alarms is shown in window 1330. 3Q 
The information in window 1330 is obtained by making 
menu selection 1332 and may be accomplished in a 
manner similar to that of window 1322. Those skilled in 
the art will understand how to implement this feature 
which has not been discussed in detail. 35 

Those skilled in the art will appreciate that object-ori- 
ented programming techniques are well suited to use in 
implementing the present inventions, and such is the 
case in the preferred embodiment. Similarly, those 
skilled in the art will appreciate that there are numerous 40 
methods which could be utilized for implementation of 
the user interface such as menu windows, bar menus, 
and the like. 

Thus it is apparent that in accordance with the pres- 
ent invention, a method that fully satisfies the aims, 45 
advantages and objectives is set forth above. While the 
invention has been described in conjunction with spe- 
cific embodiments, it is evident that many alternatives, 
modifications and variations will become apparent to 
those skilled in the art upon consideration of the forgo- 50 
ihg description. Accordingly, it is intended that the 
present invention embrace all such alternatives, modifi- 
cations and variations as fall within the spirit and broad 
scope of the appended claims. 

What is claimed is: 55 

1. A method for entering expert information into an 
expert system residing on a computer, the method com- 
prising in combination the steps of: 

said expert system providing to a user a template for 
entering a plurality of attributes for a hypothesis 60 
tree node; 

said user defining said hypothesis tree node by enter- 
ing said attributes of said hypothesis tree node into 
said template, said attributes including a first identi- 
fier for identifying said hypothesis tree node and a 65 
second identifier for identifying a second node 
connected to said hypothesis tree node by a branch 
of a hypothesis tree; 
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said expert system automatically adding said first 
identifier to a list of defined nodes, each of said 
defined nodes having said attributes defined there- 
for; 

said expert system automatically detenmning 
whether or not said second identifier is on said list 
of defined nodes; 

said expert system automatically determining 
whether or not said second identifier is not on a list 
of undefined nodes if said second identifier is not on 
said list of defined nodes, each of said unidentified 
nodes not having said attributed defined therefor; 

said expert system automatically adding said second 
identifier to said list of undefined nodes if 6aid sec- 
ond identifier is not already on said list of unde- 
fined nodes; 

said expert system automatically determining 
whether or not said first identifier is on said list of 
undefined nodes; 

if said first identifier is on said list of undefined 
nodes, removing said first identifier from said list 
of undefined nodes; and 
said expert system displaying said list of undefined 

nodes and said list of defined nodes on a screen of 

said computer. 

2. The method of claim 1, further comprising the step 
of maintaining said list of defined nodes and said list of 
undefined nodes as stack data structures. 

3. An expert system residing on a computer for use 
with a diagnostic system, comprising in combination: 

said diagnostic system including means for providing 
a plurality of types of alarms; 

said expert system including expert knowledge 
source means for defining a plurality of expert 
knowledge sources, one of said expert knowledge 
sources representing expert information for each of 
said types of alarms, said expert knowledge source 
means including node adding means for defining at 
least one of said knowledge sources to have at least 
a flow-chart node and a hypothesis tree node 
which points to said flow-chart node; 

said attributes of said template for said node being 
added including: 

a node identifier attribute which gives a name to 
said node being added, 

a node type attribute which describes fundamental 
characteristics of said node being added and 
which distinguishes between said hypothesis tree 
type node and said flow-chart type node, and 

a points-to attribute which gives the name of an- 
other node branching from said node being 
added. 

4. The expert system of claim 3, wherein said node 
adding means includes means for selecting said node 
type attribute from a list of node types. 

5. The expert system of claim 3, wherein said node 
adding means is operable for selecting at least one said 
node type attribute for said hypothesis tree node from a 
group of: AND node, OR node and Knowledge Source 
node. 

6. The expert system of claim 3, wherein said node 
adding means is operable for selecting at least one said 
node type attribute for said flow-chart tree from a 
group of: TEST node, CONCLUSION node, CALL 
node, CONFIRM node, FACT node, DELAY node 
and COUNT node. 

7. The expert system of claim 3, further comprising 
means for copying an existing node whereby, addition 
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of new node having attributes in common with said 
existing node can be accomplished by copying said 
existing node and modifying attributes which differ 
from said existing node. 

8. The expert system of claim 3, farther comprising 5 
means for modifying said node type attribute. 

9. The expert system of claim 3, further comprising 
means for modifying said node attributes. 

10. The expert system of claim 3, IQ 
wherein said alarms from said diagnostic system pro- 
vide an indication of problems detected by said 
diagnostic system to be solved by said expert sys- 
tem; and 

an alarm map means for relating types of alarms de- 15 
tected by said diagnostic system to one of said 
plurality of knowledge sources. 

11. The expert system of claim 10, further comprising 
update means for updating said alarm map means when 
new knowledge sources or new types of alarms are 20 
added to said expert system. 

12. The expert system of claim 3, further comprising 
means for displaying a graphic representation of said 
knowledge source. 25 

13. The expert system of claim 3, wherein said node 
adding means further includes: 

means for adding said node identifier attribute to a list 
containing defined nodes, said defined nodes each 
having said attributes defined therefor; 30 
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means for determining whether or not said points*to 
attribute is on said list of defined nodes; 

means for determining whether or not said points- to 
attribute is not on a list of undefined nodes if said 
points-to attribute is not on said list of defined 
nodes, said undefined nodes not. having said attri- 
butes defined therefor; 

means for adding said points-to-attribute to said list of 
undefined nodes if said points-to-attribute is not 
already on said list of undefined nodes; and 

means for displaying said list of undefined nodes and 
said list of defined nodes on a screen of said com* 
puter. 

14. The expert system of claim 3, wherein said one of 
said expert knowledge sources includes a plurality of 
hypothesis nodes, said plurality of hypothesis nodes 
including at least one high level hypothesis node and a 
plurality of sub-hypothesis nodes, said high level hy- 
pothesis points to each of said plurality of sub-hypothe- 
sis nodes, one of said sub-hypothesis nodes points to said 
flow-chart node. 

15. The expert system of claim 14, further comprising 
a second flow-chart node, said first recited flow-chart 
node points to said second flow-chart node. 

16. The expert system of claim 14, wherein each of 
said sub-hypothesis nodes point to one of a first set of 
flow chart nodes and at least a portion of said flow chart 
nodes of said first set point to another flow chart node 
from a second set of flow chart nodes. 

• » » * • 
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